[Rubygems-developers] [ rubygems-Feature Requests-27318 ] weight spec.name when searching gem lib dirs for 'path'
aaron at tenderlovemaking.com
Mon Oct 19 14:34:59 EDT 2009
noreply at rubyforge.org wrote:
> Feature Requests item #27318, was opened at 2009-10-19 11:49
> You can respond by visiting:
> 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
> 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
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)
> + first_named or first
> + end
> # Works like #find, but finds all gemspecs matching +path+.
A patch with no tests? o_O
More information about the Rubygems-developers