can frozen_gem limit script/gem list to gems only in the app

Thanks Rob ... this is already on my to-do list, but the ticket elevates it. I'll fix this on Friday.

Question in the meantime: should this be:

1. the default, with the current behavior selectable by an option
   1. an option called --system
   2. an option called --fullpath
   3. something else
2. selectable by an option
   1. an option called --frozen
   2. an option called --vendor
   3. something else

Since standard gem cmd has gem --local and gem --remote meaning the local machine's global repo (or whatever its configured to for the user) + the remote repo. Perhaps a 3rd one could be used to limit operations to the application's internal cache? script/gem --app[lication]

Oh yeah, --app is another alternative.

I think I like the idea of the default behavior showing every gem that is available to the app in the current environment, with --app restricting things to the frozen repo.

At a higher level, maybe it doesn't make sense to put much more effort into frozen_gems ( or any other gem local strategy) now that Rails 2.1 will have a built in solution?

http://ryandaigle.com/articles/2008/4/1/what-s-new-in-edge-rails-gem-dependencies http://dev.rubyonrails.org/changeset/9140 http://dev.rubyonrails.org/changeset/9215

Actually, I think frozen_gems could continue off where config.gem is just starting. Currently rails 2.1 just unpacks the gems into vendor/gems via its rake task. This means there can never be support for native C extension gems, like hpricot etc. Rather frozen_gems can support this once the next rubygems comes out with a patch to make gem pristine reinstall extensions.

Perhaps this gem could go into rails as the winning vendor/gems strategy. Since Glenn told me about it, I've liked it the best so far, fwiw.

What the new built-in solution lacks, in addition to support for native gems, is manageability.

Yep, though its nice that gems are starting to get some attention. Everyone had their own way of listing what gems were required for a project (or you didn't do it and suffered with new developers for a few hours as they complain regularly - um, so what does 'cannot load "hpricot"' mean?)

I don't know if its another ticket on here yet, but frozen_gems _should_ override the 2.1 gems rake tasks so that they behave with frozen_gems (to call script/gem instead of gem unpack or whatever they are doing now)

"Everyone had..." -> "Everyone used to have..."

Nic: the solution in edge *does* support native gems - see changset 9215 on rails trac.

I've added #9 for to track "rake gems" interop.

I agree that frozen/gems may be a more elegant, manageable solution.

However, i think this may be a case where "worse is better"...

rake gems:build - cool, didn't see that there.

This probably does lead down the "worse is better" path.

Closing this out. I think its clear now that with Rails 2.1 the built in rake gems task will lead the way.