Gavin Sinclair wrote:
> On 10/11/05, Sean E. Russell <ser / germane-software.com> wrote:
> 
>>>But what's so doggone hard or objectionable about installing gem Y if you've
>>>already  installed gem X?
>>
>>You misunderstood me.  I've already installed Y, but not as a Gem.  Now I try
>>to install X (which depends on Y).  What happens?
> 
> 
> Best case: it works because gem X only says -require 'y'-, which is
> resolved in site_ruby.
> 
> Worst case: gem X says -require_gem 'Y', '~> 1.0.2'-, which isn't
> resolved in site_ruby.  Solution: -gem install Y-  Now you've got Y
> installed in site_ruby *and* as a gem, which is not a problem.  It's
> worthwhile, because you can ensure that the *right* version of gem Y
> is there.
> 
> So you get a temporary interruption to your schedule.  All this is
> unlikely anyway, because when you installed gem X you are most likely
> to have also installed gem Y, as it was specified as a dependency.

I have a fuzzy recollection of some problems getting Rails  some 
releases ago.  Basically, installing Rails via gem would break on 
ActiveMailer (which was extra annoying as I had no need for the mailer 
lib; it is required, I guess,  because Hey, You Might Want It Some Day 
so you must install it).

Unable to resolve the issue, I go and install Rails from tarballs.  (And 
yes, at least at the time, finding them was tedious.)  Some time later, 
I retry a Rails install, have more issues, and just blow away all traces 
of Rails-related gems.  Installation via gems then goes fine.  But code 
acts funky sometimes, and I eventually track it down to the presence of 
the tarball Rails installation.  Old code installed "by hand" was 
grabbed in place of newer gems code.

Since then Ive been mindful of not having both a gem version and an 
install.rb version of any libs, so I can't say if this is still a 
problem for anyone.

James