On Mon, Feb 1, 2010 at 5:32 PM, Hugh Sasse <h...@dmu.ac.uk> wrote: > On Mon, 1 Feb 2010, Chad Woolley wrote: > > > On Mon, Feb 1, 2010 at 2:07 PM, Hugh Sasse <h...@dmu.ac.uk> wrote: > > > I see the above would be true if it were in use. My point is that his > > > project doesn't use it, and I can't impose it on him, or any arbitrary > > > project. So I agree that it will be a useful thing for new projects, > > > but for existing code bases which don't use bundler, I would > > > need something else. > > > > Ah, you don't have control over the codebase. Yeah, in that case try > > John Trupiano's code :) > > > > Also, there was some discussion a while back about adding "import" and > > "export" gem commands. I wrote some spike code which uses > > GemInstaller, and someone else wrote a different solution. That seems > > like a good place to stick this functionality, and maybe that way you > > won't have to hack it into RubyGems itself. I grabbed the 'import' > > and 'export' projects/namespaces on RubyForge, let me know if you want > > to take them over and implement this... > > OK, maybe John's code will give me a way in to this, but it just seemed > like refactoring list --local was the obvious way. But using the API > is arguably better. >
I just want to point out that gem list is going to tell you about the entire set of gems installed on a machine, not necessarily the subset of those gems that are used/activated by a given codebase. That's where I think you'll find gem_filer to be helpful. -John _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
