On 7/23/07, Eric Hodel <drbrain / segment7.net> wrote:
> On Jul 23, 2007, at 03:03, TRANS wrote:
> > On 7/22/07, Chad Fowler <chad / chadfowler.com> 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.

What isn't he saying? He's talking about having RubyGems requiring built-in.

> > 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.

I'm not talking about playing in site_lib, I've experimented with that
too -- it's a problem. Hover I think that it might be possible to meet
half-way, so to speak.

> > 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.

After bringing this subject up time and time again, you are the fist
to actually give me a concrete reply. I thank you for that. Perhaps
all my concern about it has been for not. Could you should me the code
you used to run the test? I've seen poor performance in loading up
apps before and I was under the impression that had a lot to do with
gems. Take this thread for example:

  http://rubyforge.org/pipermail/rubygems-developers/2004-December/001286.html

But maybe these issues have been addressed since 2004-5? If so great!

> > 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.

As I wrote in my first post to this thread, I'm a distinctly NOT
saying this is the moment to maker such changes, and I am all for
RubyGems going into Ruby NOW. But that certainly doesn't precluded
discussion about where that can ultimately lead. Nor do I believe this
is something to be relegated to RubyGems mailing list when it is
clearly about  the more general question of how Ruby loads libraries,
with or without gems.

When RubyGems goes into core/standard where will be the appropriate
place to talk about them then?

T.