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:
nore...@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@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
_______________________________________________
Rubygems-developers mailing list
http://rubyforge.org/projects/rubygems
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
