On Mon, Feb 1, 2010 at 10:31 AM, Hugh Sasse <h...@dmu.ac.uk> wrote: > Yes, that would do the job. I think I'm correct in thinking > geminstaller --config=/dev/null --print-rogue-gems > would do the job, as well?
No, probably not. Plus, I wouldn't recommend actually using this, since I plan to deprecate GemInstaller in favor of Bundler. I was just giving it as an example of your request, so I could point out how Bundler is superior. >> However, I believe Bundler is a better way to solve these problems. >> People should be specifying gems on a per-app or per-environment basis >> instead of relying on system gems anyway. > > Yes, that would be the ideal case, but wouldn't cover the bug hunting > case from malformed dependencies or the complete rebuild case. Not sure what you mean by malformed dependencies. In the rebuild case, you would just install ruby and rubygems, then run Bundler for the specified project/environment. >> Future versions of Bundler will also allow you to version and save the >> entire dependency tree as Bundler has resolved it (without requiring >> you to check in .gem files in cache dir, as is currently the case). > > So the versions of the version tree can go into git, etc? Yes. Bundler resolves the entire dependency tree at development-time. Currently you persist this by checking in the selected .gem files in the cache dir. Future versions will allow you to persist this without having to check in .gem files. -- Chad _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers