Re: Import gem to Ruby 1.9

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

>> I see.  The maintenance problem exists until RubyGems
>> developper adopt it.
>
> Sure.  And your LoadError fallback has the same issue.  The hack should

I maintain it.  So my tiny RubyGems loader has no such issue.

However I'm glad if it is maintained by RubyGems
developer.  But I maintain it until that.

> be maintained by RubyGems team because the check scheme depends on
> RubyGems specification.  For example, you need to check APPLE_GEM_HOME
> in rbconfig if RubyGems team accepts the patch from Apple for Leopard:
> http://rubyforge.org/pipermail/rubygems-developers/2007-October/003112.html

Thank you for the information.  I'll update my tiny RubyGems
loader if it is incorporated.

> According to DRY principle, we should not such logic in prelude.rb.

Sometimes an principle is difficult to apply.

>> RUBYOPT='-rdisable-rubygems-loader -ryour-favorite-loader'
>> disables RubyGems and enables your favorite loader.
>
> I don't like this sort of negative spell.

What's the reason?

> module Kernel
>   alias foo_hooked_require require
>
>   def require(feature)
>     begin
>       foo_hooked_require feature
>     rescue LoadError => e
>       p "do something good"
>       require feature
>     end
>   end
> end

It causes infinite recursion.
Please show a working example.

> With RUBYOPT=-rfooloader, we can hook Kernel#require before RubyGems is
> activated.  The require chain after a LoadError is as follows.
>
>   rubygems -> foo -> rubygemsloader -> original_require
>
> So foo can intercept a LoadError from rubygems.  But when an user
> activates a gem with rubygems, say rails, dependency libraries are
> activated by rubygems, too.  Now foo cannot intercept LoadError for
> these libraries.

If an application and/or an administrator use RubyGems
explicitly, RubyGems should work.  So RubyGems should work
for Rails.

If an application use gem method to activate a library,
foo cannot intercept LoadError because LoadError doesn't
raised.  So foo may not work even if a RubyGems loader
is not used by default.  foo needs to know RubyGems to work
with a library installed as a gem.

> Till ruby equips sophisticated feature loading extension point, mixing
> two or more loaders should not be expected to work.

It is very difficult to combine extensions developed
individually.

Although it is interesting problem, I don't expect it will be
solved in near future.

Do you have a concrete idea for the sophisticated feature
loading extension point?

> Incorporating your
> LoadError fallback means that Ruby allows RubyGems to be used as a only
> custom loader.  I hope I can explain myself well.

I don't understand.  What is "custom loader"?
-- 
Tanaka Akira