[Rubygems-developers] Another plug for Simon's patch

Chad Fowler chad at chadfowler.com
Wed Mar 31 10:59:25 EST 2004


On 31/3/2004, at 8:06 AM, Mauricio Fernández wrote:

> On Tue, Mar 30, 2004 at 11:08:55PM -0700, Jamis Buck wrote:
>> I currently have to do the following hack:
>>
>>   begin
>>     require 'rubygems'
>>     require_gem 'log4r'
>>   rescue Exception
>>     require 'log4r'
>>   end
>>
>
> As you said, this happens because your lib is available as a gem and a
> non-gem. Two possible solutions would be
> * dumping the non-gem version
> * having the gem version as a separate branch and using a sensible
>   configuration management system
>
> [...]
>> With Simon's patch, I simply "require 'log4r'" and leave the rest up 
>> to
>> the internals.
>
> IMHO Simon's patch is dangerous (sorry Simon ;) for the following
> reasons:
>  * installation and loading of gems are separate in rubygems

Are you suggesting that they shouldn't be separate?

>  * you can have more than one version of a lib installed
>  * require_gem (and require) defaults to the latest installed version
>
> That is, IMHO require_gem 'log4r' is evil because it doesn't isolate
> the lib from future changes in the API of log4r. Note that having the
> right version installed is not enough, you have moreover to be careful
> *not to install* a later, incompatible version; this can be tricky 
> since
> the new version could be required by some other gem.
>

"evil", I suppose, means "horrible"?  I think it comes down to how 
careful you want to be and how stable the libraries you depend on tend 
to be.  Also, look at the current non-rubygems scenario: require 
'log4r' is going to result in broken code if you install a later, 
incompatible version.  With RubyGems, if this breaks, you go into your 
code and change one line, requiring "<= broken.version".  That seems 
considerably less "evil" than the current "require" in this context.


> If rubygems doesn't guarantee that the right one will be used, in
> practice you cannot install several versions of a library, unless they
> are compatible (in which case there's little merit in keeping an older
> one).
>

I don't feel that you have fully demonstrated this assertion here.   At 
any rate, actual "in practice" reports will help us sort this out.  
That's the reason for Alpha releases, right? :)  We can sort all of 
this out before RubyGems reaches a final release by listening to real 
experience reports from the community.

> I believe
>  require_gem 'log4r'
> should be
>  require_gem 'log4r', ">1.0.5" # implicit < 2.0 and assumes a 
> versioning
>                                # policy
>

I understand the potential need for multiple relational requirements, 
but I personally hate the implicit "< 2.0" idea here.  I would be more 
accepting of the more verbose:

    require_gem "log4r", "> 1.0.5", "< 2.0.0"

This is definitely a good discussion.  Let's keep it going.

(btw, I'm sure this is going to be completely out of date by the time 
it's sent.  I'm writing in offline mode on the airplane.  6 more hours 
til I'm home).

Chad



More information about the Rubygems-developers mailing list