[Rubygems-developers] [ rubygems-Feature Requests-27318 ] weight spec.name when searching gem lib dirs for 'path'

Adam Salter adam.q.salter at gmail.com
Tue Oct 20 02:42:01 EDT 2009


This change makes sense to me.
Straight alphabetical sorting seems unfair and maybe a little insecure  
somehow. Installing 'aaaGem' could potentially wreak havoc, or make a  
very good little man in the middle gem.

I'm not sure if this change would fix this problem, but I do recall  
seeing a similar problem in the dbd-odbc library:

http://ruby-dbi.rubyforge.org/git?p=ruby-dbi.git;a=blob;f=lib/dbd/ODBC.rb;h=2c531b52613295ac802bdd880d668b159e52b0ca;hb=HEAD#l33

Line 33:

-Adam

On 20/10/2009, at 5:34 AM, Aaron Patterson wrote:

> noreply at rubyforge.org wrote:
>> Feature Requests item #27318, was opened at 2009-10-19 11:49
>> You can respond by visiting:
>> http://rubyforge.org/tracker/?func=detail&atid=578&aid=27318&group_id=126
>>
>> Category: local package management
>> Group: None
>> Status: Open
>> Resolution: None
>> Priority: 3
>> Submitted By: ara howard (ahoward)
>> Assigned to: Nobody (None)
>> Summary: weight spec.name when searching gem lib dirs for 'path'
>>
>> Initial Comment:
>> gems has a *serious* issue in that someone structuring there gem like
>>
>>  a_gem-1.2.3/lib/rails.rb
>>
>> will have there rails.rb loaded *before* the actual rails.rb when  
>> one does a
>>
>>  require 'rails'
>>
>> this because the search through gem libdirs is sorted alpha/version  
>> wise with no concept of the semantics of the require statement.  in  
>> fact, we know that users of rubygems mean to require the gem  
>> *named* rails when issuing the above.  no gem user issues a normal  
>> require to pick up some random file from inside and arbitrary gem  
>> libdir.  as such it makes sense to *prefer* file matches which  
>> exactly match the spec.name when searching.  here is a patch, all  
>> tests that passed before (there was one failing) continue to pass  
>> with this patch:
>
> I don't think this is a problem rubygems necessarily needs to  
> solve.  As
> a library writer, why are you including a lib/rails.rb in your gem?   
> Why
> not "lib/a_gem/rails.rb"?
>
> I wouldn't use a gem where the gem author didn't realize the
> implications of included a top-level rb file that conflicted with  
> other
> gems.  It seems like bad form.
>
>> --- lib/rubygems/gem_path_searcher.rb.org	2009-10-19  
>> 11:37:13.000000000 -0600
>> +++ lib/rubygems/gem_path_searcher.rb	2009-10-19 11:46:26.000000000  
>> -0600
>> @@ -30,8 +30,11 @@
>>   # Return the _gemspec_ of the gem where it was found.  If no match
>>   # is found, return nil.
>>   #
>> -  # The gems are searched in alphabetical order, and in reverse
>> -  # version order.
>> +  # The gems are searched in alphabetical order, and in reverse  
>> version order.
>> +  # If a path is found in more than one gem the gem with a  
>> spec.name == path
>> +  # is preferred over others - in otherwords main-3.0.3/lib/ 
>> main.rb would be
>> +  # preferred over geonames-1.2.3/lib/main.rb if one issued a  
>> 'require "main"'
>> +  # - assuming main had spec.name=='main'.
>>   #
>>   # For example:
>>   #
>> @@ -46,8 +49,18 @@
>>   # only that there is a match.
>>
>>   def find(path)
>> -    @gemspecs.find do |spec| matching_file? spec, path end
>> +    first_named = first = nil
>> +    @gemspecs.select do |spec|
>> +      if(matching_file?(spec, path))
>> +        name = File.basename(path).sub(%r/\..*$/,'')
>> +        first ||= spec
>> +        first_named ||= spec if(spec.name == name)
>> +      end
>> +      break if(first_named and first)
>>   end
>> +    first_named or first
>> +  end
>> +
>>
>>   ##
>>   # Works like #find, but finds all gemspecs matching +path+.
>
> A patch with no tests?  o_O
>
> -- 
> Aaron Patterson
> http://tenderlovemaking.com/
> _______________________________________________
> Rubygems-developers mailing list
> http://rubyforge.org/projects/rubygems
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers



More information about the Rubygems-developers mailing list