From: Eric Hodel <drbrain@...7.net>
Date: 2007-07-26T13:07:57+09:00
Subject: Re: Import gem to Ruby 1.9

On Jul 25, 2007, at 18:55, NAKAMURA, Hiroshi wrote:
> Eric Hodel wrote:
> >> This mail is for the topic '4. What $LOAD_PATH order should be?'
>
> >>   # We replace Ruby's require with our own, which is capable of
> >>   # loading gems on demand.
> >>   #
> >>   # When you call <tt>require 'x'</tt>, this is what happens:
> >>   # * If the file can be loaded from the existing Ruby loadpath, it
> >>   #   is.
> >>   # * Otherwise, installed gems are searched for a file that  
> matches.
> >>   #   If it's found in gem 'y', that gem is activated (added to the
> >>   #   loadpath).
> >>   #
> >>   # The normal <tt>require</tt> functionality of returning false if
> >>   # that file has already been loaded is preserved.
> >
> > The work of adding the gem's require_paths to $LOAD_PATH happens in
> > Gem::activate.
> >
> >> Custom 'require' at first try to load the specified feature name  
> from;
> >> [-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .]
> >> When it raises LoadError then add GEMs at the top of $LOAD_PATH  
> and try
> >> to load the feature from;
> >> [GEMs, -I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .]
> >
> > The behavior you describe is how 0.9.2 and previous worked.
>
> Doh.  Sorry for bothering you.  I updated rubygems with
> 'gem update --system' and I confirmed that the behavior change you
> explained.
>
> > With GEMs before -I, the gem version can get loaded instead of  
> the -I
> > version.
> >
> > With GEMs after -I, the -I version will always be preferred.
>
> Agreed.
>
> So the topic 4-2 should be;
>
>   4. What $LOAD_PATH order should be?
>     4-2. after requiring rubygems?
>       [-I, ENV_RUBYLIB, GEMs, SITELIBDIR, RUBYLIBDIR, .]
>
> As I wrote in the latest summary, this behavior should be up to  
> RubyGems
> team.  RubyGems team can control this behavior.
>
> Then why I raised the topic to this thread?  Because I considered that
> RubyGems may be enabled by default.
>
> Eric,
>
>   - you are thinking that $LOAD_PATH does not include GEMs dirs by
>     default.
>   - you think that 'hooking -r option' is all the requirement for
>     ruby/1.9.1 to bundle RubyGems.
>
> Right?  So the expected behavior is as follows?
>
> % gem install httpclient
> (done)
> % ruby -rhttpclient -e 'p HTTPClient.get_content("http://localhost/")'
> => ruby: no such file to load -- httpclient (LoadError)
> % ruby -rgem -rhttpclient -e '...'
> => (runs fine)
>
> Of course we can direct users to use RUBYOPT=-rgem trick to hide this
> detail though.

Yes.  Not everybody will need RubyGems.  For example many Rails  
installations run with everything unpacked into a local directory for  
easy deployment.

I would prefer users use RUBYOPT instead of enabling RubyGems by  
default.

> I think RubyGems should not be enabled by default but once after using
> RubyGems, GEMs dir should be checked without any trick until the  
> time I
> run 'gem cleanup'.  Of course any other Ruby based new packaging  
> system
> can do the same thing.  Isn't it the behavior we expect to a packaging
> system?
>
> As you know, it requires rather complicated 'require-hook' feature to
> ruby such as;
>
>  - ruby checks "custom_require.rb" file in SITELIBDIR and load it  
> before
>    enabling any feature.
>
> It may be too much for ruby/1.9.1.  'To use gem, run ruby with "-rgem"
> always' can be accepted for the first step I think.

I was hoping we could use rb_funcall to invoke a Kernel#require in  
require_libraries() rather than calling the C rb_require directly.   
Is this possible?

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