gem versioning patch doesn't seem to have been applied to HEAD

gem versioning patch doesn't seem to have been applied to HEAD

[Dave Thomas]

A while back, I believe that Rich Kilmer created a patch to gems in  
1.9 that fixed the following:

dave[RUBY3/Book 12:05:12] gem list builder

*** LOCAL GEMS ***

builder (2.1.2, 0.1.1)

dave[RUBY3/Book 12:05:16] irb
irb(main):001:0> $:.grep /builder/
=> ["/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-2.1.2/lib"]
irb(main):002:0> gem 'builder', '< 1.0'
=> true
irb(main):003:0> $:.grep /builder/
=> ["/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-2.1.2/lib",  
"/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-0.1.1/lib"]


(The 0.1.1 gem is in the include path _after_ the default, so it won't  
get loaded by a subsequent require)




Dave

Re: gem versioning patch doesn't seem to have been applied to HEAD

[ara howard]

On Feb 6, 2008, at 11:08 AM, Dave Thomas wrote:

> A while back, I believe that Rich Kilmer created a patch to gems in  
> 1.9 that fixed the following:
>
> dave[RUBY3/Book 12:05:12] gem list builder
>
> *** LOCAL GEMS ***
>
> builder (2.1.2, 0.1.1)
>
> dave[RUBY3/Book 12:05:16] irb
> irb(main):001:0> $:.grep /builder/
> => ["/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-2.1.2/lib"]
> irb(main):002:0> gem 'builder', '< 1.0'
> => true
> irb(main):003:0> $:.grep /builder/
> => ["/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-2.1.2/ 
> lib", "/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-0.1.1/ 
> lib"]
>
>
> (The 0.1.1 gem is in the include path _after_ the default, so it  
> won't get loaded by a subsequent require)
>
>
>
>
> Dave

i didn't see the patch, but i've had fits with this a few times and  
spoke with eric about it.  the load path is backwards for sure.  a  
larger problem, imho, is that gems is loading libraries by  
manipulating the global load path.  am i the only one that thinks this  
is evil?  just randomly throwing the load path of a gem into the  
global path seems fraught with peril to me...

on a related note though, and fix will break old code that was using  
versioning since the load path will end up completely different - it's  
rather sticky....

a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama

Re: gem versioning patch doesn't seem to have been applied to HEAD

[Eric Hodel]

On Feb 6, 2008, at 10:08 AM, Dave Thomas wrote:

> A while back, I believe that Rich Kilmer created a patch to gems in  
> 1.9 that fixed the following:
>
> dave[RUBY3/Book 12:05:12] gem list builder
>
> *** LOCAL GEMS ***
>
> builder (2.1.2, 0.1.1)
>
> dave[RUBY3/Book 12:05:16] irb
> irb(main):001:0> $:.grep /builder/
> => ["/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-2.1.2/lib"]
> irb(main):002:0> gem 'builder', '< 1.0'
> => true
> irb(main):003:0> $:.grep /builder/
> => ["/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-2.1.2/ 
> lib", "/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-0.1.1/ 
> lib"]
>
>
> (The 0.1.1 gem is in the include path _after_ the default, so it  
> won't get loaded by a subsequent require)

Try r15423.  Sorry it took so long.

Re: gem versioning patch doesn't seem to have been applied to HEAD

[Richard Kilmer]

On Feb 8, 2008, at 12:39 AM, ara howard wrote:

>
> On Feb 6, 2008, at 11:08 AM, Dave Thomas wrote:
>
>> A while back, I believe that Rich Kilmer created a patch to gems in  
>> 1.9 that fixed the following:
>>
>> dave[RUBY3/Book 12:05:12] gem list builder
>>
>> *** LOCAL GEMS ***
>>
>> builder (2.1.2, 0.1.1)
>>
>> dave[RUBY3/Book 12:05:16] irb
>> irb(main):001:0> $:.grep /builder/
>> => ["/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-2.1.2/lib"]
>> irb(main):002:0> gem 'builder', '< 1.0'
>> => true
>> irb(main):003:0> $:.grep /builder/
>> => ["/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-2.1.2/ 
>> lib", "/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-0.1.1/ 
>> lib"]
>>
>>
>> (The 0.1.1 gem is in the include path _after_ the default, so it  
>> won't get loaded by a subsequent require)
>>
>>
>>
>>
>> Dave
>
> i didn't see the patch, but i've had fits with this a few times and  
> spoke with eric about it.  the load path is backwards for sure.  a  
> larger problem, imho, is that gems is loading libraries by  
> manipulating the global load path.  am i the only one that thinks  
> this is evil?  just randomly throwing the load path of a gem into  
> the global path seems fraught with peril to me...

The require/load hack in RubyGems before modified the global load path  
when you loaded a gem.  What this is basically saying is that the  
highest version gem _IS_ part of your load path (again, this is what  
the require/load hack did).  We now just do this explicitly and  
efficiently  up front so we don't have to override require and load  
which was much more evil IMHO.  We now also don't need to load much of  
rubygems  until you explicitly load a Gem of a different version (say  
and earlier version) then it faults in the full gem support.  You can  
always disable it with ruby --disable-gems :-)

-rich

>
>
> on a related note though, and fix will break old code that was using  
> versioning since the load path will end up completely different -  
> it's rather sticky....
>
> a @ http://codeforpeople.com/
> --
> we can deny everything, except that we have the possibility of being  
> better. simply reflect on that.
> h.h. the 14th dalai lama
>
>
>
>