Re: Import gem to Ruby 1.9

In article <[e-mail]>,
  "NAKAMURA, Hiroshi" <[e-mail]> writes:

> I think that RubyGems team possibly does not like this kind of logic
> duplication.  Note that it's just a thought of mine.  I've heard nothing
> about this from RubyGems team.

The logic is not identical.  RubyGems itself (and yours) is
accurate but memory consuming.  My tiny RubyGems loader is
not accurate but not memory saving

They are difficult to unify them.

> Code duplication and independent maintainer as I wrote above.

They cause maintainance cost, but I take it.  Any other
problem?

> If it's not evil or worse, just let users use RUBYOPT as a charm to use
> rubygems.  What's the difference?  But...

RUBYOPT is not required for using RubyGems.
disable-rubygems-loader.rb is used for disabling RubyGems.

I know you try to force us to use RUBYOPT for RubyGems.  But
I don't want to define RUBYOPT to simply use a installed
library.

> Here's my try;

Oops.  I tryed with internal version which try to remove
RubyGems loader.

However I can't reploduce your problem.

> module Kernel
>   alias original_require require
>   def require(feature)
>     original_require feature
>   rescue LoadError
>     if require 'rubygems'
>       require feature
>     else
>       raise
>     end
>   end
> end

I modified this to check LoadError at require 'rubygems'.

module Kernel
  alias _original_require require
  def require(feature)
    _original_require feature
  rescue LoadError => e
    if begin
         _original_require 'rubygems'
       rescue LoadError
         raise e
       end
      require feature
    else
      raise
    end
  end
end

> 0% cat foo.rb

foo.rb is exactly as yours.

> 0% RUBYOPT=-rfoo ruby19 -e 'require "httpclient"'
> /usr/local/lib/ruby/site_ruby/1.9/gemloader.rb:44: warning: already
> initialized constant OPS
> /usr/local/lib/ruby/site_ruby/1.9/gemloader.rb:94: warning: already
> initialized constant Requirement
> gemloader.rb intercepted rubygems loading
> /usr/local/lib/ruby/site_ruby/1.9/rubygems/specification.rb:629:in
> `method_missing': undefined method `<<' for {}:Hash (NoMethodError)
>         from
> /usr/local/lib/ruby/site_ruby/1.9/rubygems/specification.rb:629:in
> `add_dependency'

% ./ruby -rfoo -e 'require "redcloth"; p RedCloth' 
/home/src/ruby/gems19/ruby/gemloader.rb:44: warning: already initialized constant OPS
/home/src/ruby/gems19/ruby/gemloader.rb:94: warning: already initialized constant Requirement
RedCloth
% ./ruby -rfoo -e 'require "httpclient"'          
/home/src/ruby/gems19/ruby/gemloader.rb:44: warning: already initialized constant OPS
/home/src/ruby/gems19/ruby/gemloader.rb:94: warning: already initialized constant Requirement

The exception is not raised.

Note that I used gemloader.rb r13.
(Actually I used r12 supporting 1.9 myself at first.  It is
almost identical with r13.)

> The last exception is the 'Name crash' I wrote in the previous mail.

I'm not sure what causes your exception.

However I'm thinking to update my proposal to use
[ruby-dev:32161].

> Now foo.rb loads gemloader.rb but think when I want to use one of a
> custom loader (not existing now) I wrote in [ruby-core:12774].  Say
> signed tarball loader.  It might have another repository which has
> signed tarballs but RubyGems loads a gem instead of it, isn't it?

If a gem is installed, yes.  If a gem is not installed, no.

>> Do you think about that an administrator installs a library
>> as a gem but an user doesn't want to use it?
>
> Hmm.  I didn't think about it in detail but yes, it should be a
> situation I'm wondering about.  For example, a Leopard user may want to
> use mydevelgemloader.rb which only loads gems from ~/mydevel/gems.

In the condition under conflicts between an administrator
and an user, it is very difficult to solve the problem.

I think (or hope) such conflicting situation is rare.
An administrators intention, use a installed gem, should be
used by default.
-- 
Tanaka Akira