Re: Import gem to Ruby 1.9

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

Hi,

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

Agreed.

> They are difficult to unify them.

Might true.  The way for letting it be unifyable can introduce some
other constraints I think.  For example, adding a rule for Gem
specification that 'gem creator must use 'lib' directory for
require_path in Gem::Specification' or so.

>> Code duplication and independent maintainer as I wrote above.
> 
> They cause maintainance cost, but I take it.  Any other
> problem?

No other problem I have for now.  But I'm still thinking RubyGems team
might not want it.  I heard that authors want to keep rubygems for 1.8
and 1.9 in sync.  I respect their vision.

Why don't you wait for the response?  Can somebody ask it in RubyConf?

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

I can understand it.  I too don't want to define RUBYOPT to use my
custom loader instead of RubyGems even if gems are installed by an
administrator.

It's about time we should summarize pros and cons of the ways we can
take.  It's a balancing issue, isn't it?

>> Here's my try;
> 
> Oops.  I tryed with internal version which try to remove
> RubyGems loader.
> 
> However I can't reploduce your problem.

>> The last exception is the 'Name crash' I wrote in the previous mail.
> 
> I'm not sure what causes your exception.

Sorry.  I wrongly set GEM_PATH to another point.  This repository
contains gems which has dependencies and causes
Gem::Specification#add_dependency crash.  Now I get the same result as
yours.

0% ruby19 -rfoo -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
gemloader.rb intercepted rubygems loading
gemloader.rb intercepted rubygems loading
gemloader.rb intercepted rubygems loading
gemloader.rb intercepted rubygems loading

Anyway, the name crash is not important.  Back to the topic,

[ruby-core:12935]
> Would you show me a loader which doesn't work well with my
> loader?

I wrote a proof-of-concept custom loader 'unloadable.rb'.
http://dev.ctor.org/vtr/browser/trunk/lib/unloadable.rb
It (incompletely for now) allows user to unload a library.  See the head
of unloadable.rb for the definition of 'unload'.

Here's a script.  soap/soap is (still) installed in libdir of 1.9.
httpclient is installed as a gem.  prelude.rb is not changed (does not
include infinite loop detection but it won't affect I think).

0% ruby19 -d -runloadable -e 'require "soap/soap"; unload "soap/soap"'
[...]
removing constants: [:XSD, :Iconv, :SOAP]
[...]

0% ruby19 -d -runloadable -e 'require "httpclient/cookie"; unload
"httpclient/cookie"'
[...]
removing constants: [:RbConfig, :Config, :CROSS_COMPILING, :Gem,
:ConditionVariable, :Queue, :SizedQueue, :Forwardable,
:SingleForwardable, :Rational, :Date, :DateTime, :FileUtils, :Etc, :URI,
:WebAgent, :ParseDate]
[...]

RubyGems features are unexpectedly unloaded in the second execution.
For this issue, enabling RubyGems by default without tiny loader solves
the problem.

0% ruby19 -d -rubygems -runloadable -e 'require "httpclient/cookie";
unload "httpclient/cookie"'
[...]
removing constants: [:FileUtils, :Etc, :URI, :WebAgent, :ParseDate]
[...]

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

Sure.  I'll reply to ruby-dev.  We run this thread too much so no one
seems to be following here.

It's the best I think if we have such an extension point for custom
loaders and if RubyGems use it instead of replacing require.  But as I
wrote in [ruby-core:12827], we don't have enough time to do before 1.9.1
I think.  Do you think it happen?

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

Sure.

For reality, I wrote another proof-of-concept custom loader
'signedloader.rb'
http://dev.ctor.org/vtr/browser/trunk/lib/signedloader.rb
It tries to restrict to load features from configured dirs (libdir,
archdir, sitelibdir, sitearchdir, not including "." and others)

Here's a script.  ruby is ruby_1_8 version.  ruby19 is trunk version.
For 1.8, httpclient is installed in sitedir.  For 1.9, httpclient is
installed as a gem (no httpclient in sitedir).

0% ruby -rsignedloader -e 'require "httpclient/cookie"; p $".find_all {
|f| /httpclient/ =~ f }'
["signedloader:httpclient/cookie.rb"]

0% ruby19 -rsignedloader -e 'require "httpclient/cookie"; p $".find_all
{ |f| /httpclient/ =~ f }'
["/usr/local/lib/ruby/gems/1.9/gems/httpclient-2.1.2/lib/httpclient/cookie.rb"]

I use signedloader.rb to intercept RubyGems to load httpclient so the
second execution should raise a LoadError.

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

I can understand your thought (or hope).  Once Ruby "core team" (should
be Matz, this time) will decide this rather tight merge with RubyGems as
a design, with knowing this kind of rare issues, I'll live with that in
other way, for example, developing 'easily unloadable loader extension
point' such as your [ruby-dev:32161].

Regards,
// NaHi

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

iQEVAwUBRyk72x9L2jg5EEGlAQLPDQf/TbmqdHAAjDlTa7XlqdydwKmJJg+RbTzI
bRb1YoknAqlOI2C3T69mnHFYOcTxMsBgQcN9ytEtxaAh2Gs5Z/ZgD08nqmUrAROr
5K1Y6PRtREHdZHUKdmupVlkGD3BWy5gnuKo5OiDDQqrRAktAM0GYmA2k+Vw3O3yE
cnKleTRdzOYSwVjyXspcaw5Eiq1JFUtXWQwgtoBsqHlzWf/VNsL3aRn0rgG2k3f7
PIlasjHdknM3rxQ7JiNm0x2xccPkwJectQd7orX2f8S/jyvSAk244rGPfnu+RoJy
NGAoRGnxc10pO1G6EzifUBqeBWvGFJiIKHZ+5ODRclvEFWXp6B4w/w==
=p2lo
-----END PGP SIGNATURE-----