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

Reply via email to