Re: Import gem to Ruby 1.9

On Jul 23, 2007, at 03:03, TRANS wrote:
> On 7/22/07, Chad Fowler <[e-mail]> wrote:
>>
>> A built-in require hook would be excellent.  I'm sure I'm going to
>> raise some feathers here but if we're going to include RubyGems in  
>> the
>> distribution, what is the general feeling about just including the
>> RubyGems LOAD_PATH semantics as part of how #require naturally works?
>> That would mean either of two things:  1) #require is enhanced in  
>> C to
>> do the RubyGems logic of looking in the installed gems and adding to
>> the LOAD_PATH + requiring on match or 2) require 'rubygems' by
>> default.
>
> No at all. That's actually what I've been advocating. But rather than
> hobble two different require mechanisms, one on top of the other,

This isn't what Chad is saying.  We're going to add code to call back  
through RubyGems' custom_require from C, or some similar solution.

> we should create an improved unified mechanism -- unifying gems/  
> and site_lib/.  That's really the way to go, though there are some  
> considerations.

This isn't going to happen.  RubyGems abandoned playing in site_lib  
ages ago for various well-founded reasons, and isn't going back.

> 1) Efficiency. Gems adds a lot of dirs to the load path. While the
> normal require mechanism only has a few. When running a small script,
> no one wants to wait, even for 1 second, for a lib to be found. Is
> there a good way to address this?

Your claim of 1 second is highly implausible:

1000 runs with 77 extra load paths
Rehearsal -------------------------------------------
empty     0.000000   0.000000   0.000000 (  0.000097)
regular   3.160000   0.290000   3.450000 (  3.444110)
many      4.270000   3.920000   8.190000 (  8.210680)
--------------------------------- total: 11.640000sec

               user     system      total        real
empty     0.000000   0.000000   0.000000 (  0.000118)
regular   3.180000   0.290000   3.470000 (  3.484868)
many      4.290000   3.940000   8.230000 (  8.278954)

This shows an average of 1.1 ms more time to search those 77 extra  
paths, so you'd need about 77000 load paths active to cause a 1  
second delay.  There aren't even 2000 unique gems.

> 2) Organization of the gems/ directory. [...]
> 3) Per the last point. I'd rather see a tiered layout [...]

These aren't changing.

> 4) The gemspec should not be crucial to using the gems repository. The
> only piece of info in there that I think is required is the
> load_paths. Most packages don't need it. So a gemspec for a package
> should be optional --which is necessary to be able to install a
> package manually or via other package systems too.

Try require_paths, dependencies, required_ruby_version, ...

This isn't changing either.

This is not the time to discuss or make major, destabilizing  
architectural changes to RubyGems.

This is not the place to be advocating any shopping list for  
RubyGems.  The correct place for that is the RubyGems mailing list,  
and the RubyGems tracker.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars