From: "NAKAMURA, Hiroshi" <nakahiro@...>
Date: 2007-10-29T10:09:37+09:00
Subject: Re: Import gem to Ruby 1.9

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Tanaka Akira wrote:
>>> 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.

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

>> According to DRY principle, we should not such logic in prelude.rb.
> 
> Sometimes an principle is difficult to apply.

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

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

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

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

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.

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

Sure.

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

Yes.

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?

	/	/	/

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

Agreed to all.  I don't have nothing to write down but I'll post a reply
to [ruby-core:12783] when I give a think about it.

Regards,
// NaHi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iQEVAwUBRyUyrh9L2jg5EEGlAQJO+ggAhT1Cw5pqB0ym2aYUW1oJ8cjB6phl68m+
iNawOISKaZJapoHRPo/3BqJ7Ah5tdAD/FHtmoiwXF8i3xAfG5Cb0ZGdcVEkpp///
xUwhSsJv0uko+yMXoYU3rfycyZX/ZJwQJ7Z2B2PsPdzanj3GxVWGguuwNcusBvYJ
0xEeVaNgwJF5nCqdKo8Is8CWwUGgSJe7SGppHLUQx6Pi4yBm1PEDjSIUEgCD1bcO
Hm3dVjBvyXNkpfwjbdJ7p/qQXanzh7+1a3rOfQlPyRDyxfHWZ2HyknId7CAddgWb
lrpeDciWBG7ZOxO49iKFnVly0HATgdGFVsB/JVDwJBdJV0ZaBwcTAg==
=4JFi
-----END PGP SIGNATURE-----