Re: Import gem to Ruby 1.9

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

Hi,

This mail is for the topic '4. What $LOAD_PATH order should be?'

Eric Hodel wrote:
>>   4-2. after requiring rubygems?
>>     [-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, ., GEMs] or
>>     [-I, ENV_RUBYLIB, SITELIBDIR, GEMs, RUBYLIBDIR, .] or
>>     [-I, ENV_RUBYLIB, GEMs, SITELIBDIR, RUBYLIBDIR, .]
>>
>>    - the first one is the current RubyGems behavior and it should not be
>>      changed as far as RubyGems team do not change it.  the behavior
>>      must have been polished up in several years.
> 
> Actually, the last one is current default:
> 
>   [-I, ENV_RUBYLIB, GEMs, SITELIBDIR, RUBYLIBDIR, .]
> 
> This works best for developers who want to work on multiple gems at
> once, since they can use ruby -I to source the development version
> instead of the gem version.

I may misunderstand custom_require.rb.  I'm seeing custom_require.rb
revision 1285.

  # We replace Ruby's require with our own, which is capable of
  # loading gems on demand.
  #
  # When you call <tt>require 'x'</tt>, this is what happens:
  # * If the file can be loaded from the existing Ruby loadpath, it
  #   is.
  # * Otherwise, installed gems are searched for a file that matches.
  #   If it's found in gem 'y', that gem is activated (added to the
  #   loadpath).
  #
  # The normal <tt>require</tt> functionality of returning false if
  # that file has already been loaded is preserved.

Custom 'require' at first try to load the specified feature name from;
[-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .]
When it raises LoadError then add GEMs at the top of $LOAD_PATH and try
to load the feature from;
[GEMs, -I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .]
I concaticated 2 arys and called Array#uniq (I hope Array#uniq keeps its
order in the future, too).  Is this wrong?

And when we call 'gem "soap4r"' explicitly, the $LOAD_PATH is;
[GEMs, -I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .]
isn't it?

I should have wrongly summarized the problem.  Can you sort out a
problem about $LOAD_PATH?

>>    - maybe I (NaHi) is the only person who have a very hard time with
>>      this behavior in soap4r-ML.  it's because soap4r is the only lib
>>      which is gem-ed and located in RUBYLIBDIR.  that's exactly why I
>>      run this thread.
> 
> If soap4r were unbundled, would this matter anymore?  (I forgot the
> details of the problems of soap4r in RUBYLIBDIR and soap4r gem.)

No, it won't be the matter anymore.  So the followings are just an
explanation what was happened.

Say an user gets ruby/1.8.6 (based on soap4r-1.5.5).  Then installs
soap4r-1.5.6 from tarball later (files are copied to site_lib dir).
 Finally moves to RubyGems and installs soap4r-1.5.7 as a gem.

soap4r-1.5.5 has a feature 'soap/a'.
soap4r-1.5.6 adds new feature 'soap/b'.
soap4r-1.5.7 adds another new feature 'soap/c'.

soap/c depends on soap/b.  soap/b depends on soap/a.
soap/a and soap/b are updated in each new version.

  /usr/lib/ruby/1.8/soap/a                            # soap4r-1.5.5
  /usr/lib/ruby/1.8/site_ruby/soap/a                  # soap4r-1.5.6
  /usr/lib/ruby/1.8/site_ruby/soap/b                  # soap4r-1.5.6
  /usr/lib/ruby/gems/1.8/gems/soap4r-1.5.7/lib/soap/a # soap4r-1.5.7
  /usr/lib/ruby/gems/1.8/gems/soap4r-1.5.7/lib/soap/b # soap4r-1.5.7
  /usr/lib/ruby/gems/1.8/gems/soap4r-1.5.7/lib/soap/c # soap4r-1.5.7

Imagine what is loaded when the user runs 'require "soap/c"'.
 Thankfully there's an easy answer how to avoid this; to load the
consistent feature versions, add 'gem "soap4r"' somewhere in a program.
 Once an user found this answer, it gets easier to track down a loader
problem in soap4r-ml.  The rest I want to know is where 'gem "soap4r"'
should be added in RoR environment... (I've not yet been a RoR user.)

// NaHi

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

iQEVAwUBRqa7LB9L2jg5EEGlAQIYaQf/Srn1d9JuqD+3z9wX3lscK2SsJjphDHHf
bMrSz73gDkExvcsvk13YGzqiZTzWu1OdL3Kxf8SUkrQYNz0I6nQ+aw4sFqglhLqU
NwFuViUY+KxeVxR8OP62i7Q+luGcCuA2ziXaopAZ/4C/McLsi93KvE1PXiM/vAAP
WTMcfAOcjTnP177kZbVPxFajZOp4PSLw5mh++FwxF9pdyzLxGoWrEiY8RxbuSthp
vnKC/9+q2+zNnxZwvrIed38W03ifL2PmA0DsQRYk8lsxArD757G4L7baVCgGseA9
LdxvU4Jz0XylbCECWxGTiBquJhcDArVnjWFbaV96VHZjvA5ctuF8aw==
=uSVl
-----END PGP SIGNATURE-----