From: Tanaka Akira <akr@...>
Date: 2007-10-30T13:58:42+09:00
Subject: Re: Import gem to Ruby 1.9

In article <472532B0.2060600@sarion.co.jp>,
  "NAKAMURA, Hiroshi" <nakahiro@sarion.co.jp> writes:

> Oh, I didn't think you maintain it.  But let's wait for what RubyGems
> team think about the way you go.

RubyGems developers can choose to maintain or not.  I don't
think there is a problem.

This is a critical difference of your proposal and mine.

> Definitely.  But it's a built-in logic of a ruby interpreter/Ruby
> language.  We should be cautious.

Do you have a concrete problem?

> All spell are evil and spell for denying somethig are worse because it
> generally don't work well and causes incomprehensible behavior.

I don't think it is evil or worse.  Do you have a concrete
problem?

Since it is intended to used as at first in RUBYOPT, I think
it works.

> Sorry for confusing you.  You should know you can do anything at 'p "do
> something good"' line because it's excerpted from your tiny rubygems
> loader.  For example, replace;
>   p "do something good"
> with;
>   raise unless require 'gemloader'
>
> This causes Name crash between rubygems and gemloader but it's not the
> issue I want to point out as I wrote in the previous mail.

My tiny RubyGems loader and your above code doesn't conflict.

% cat fooloader.rb 
module Kernel
  alias foo_hooked_require require

  def require(feature)
    begin
      foo_hooked_require feature
    rescue LoadError => e
      raise unless require 'gemloader'
      require feature
    end
  end
end
% RUBYOPT=-rfooloader ./ruby -e 'require "redcloth"; p RedCloth'
RedCloth

The above ruby has my loader in prelude.rb.  RedCloth is
installed as a gem.  RUBYOPT=-rfooloader doesn't cause a
trobule: RedCloth can be required as usual, as fooloader
expected.

I know fooloader doesn't run in this case because my loader
run.  However the result is identical: RedCloth is loaded.
The two extensions doesn't conflicts because they does
exactly same task.

Please show working and conflicting example.

> And those 2 behavior are not the point I wrote above.  Even if an user
> want use another custom loader, your tiny rubygems loader loads rubygems
> and a LoadError can activate gems.  As the result, the custom loader
> cannot intercept the LoadError.  Am I misunderstand something?

I guess I don't understand the your point.

If an administrator installs a library as a gem, the library
is expected to use.  If the library is not installed,
LoadError is raised.

Do you think about that an administrator installs a library
as a gem but an user doesn't want to use it?
-- 
Tanaka Akira