Re: Import gem to Ruby 1.9

On Jul 24, 2007, at 06:44, NAKAMURA, Hiroshi wrote:
> Thanks all for your discussions.  I updated the list with your  
> comments
> and mine.
>
> Note that 'ruby' means MRI in this mail.
>
> 1. Is platform-specific gem handling needed in ruby/1.9.1?
>
>   - Is binary gem support needed in ruby/1.9.1?
>     (Independent from this, RubyGems will support this useful feature)

binary/platform gem support is not absolutely necessary for 1.9.1.   
If the timeframe is inclusion in October, that's plenty of time to  
get the feature implemented.

> 2. Does RubyGems need some 'require-hook' feature to be added to
>    ruby/1.9.1?  What's the requirements?
>
>   - not needed. integrate RubyGems with ruby's require.
>   - just bundle RubyGems with ruby as one of a packaging system.
>     so hooking -r options as same as Kernel#require is needed.

Yes.

>   - Nobu, I heard that you have once designed this feature halfly.
>     Is there anything you can share with us?
>
> 3. What gem related commands should be install in BINDIR by the  
> standard
>    installer?
>      gem, gemlock, gemri, gemwhich, gem_mirror, gem_server,
>      index_gem_repository.rb, update_rubygems
>
>   - nothing should be installed
>     ('ruby -rgem -e update gemname' should enough)
>   - moving everything under the 'gem' command and install only 'gem'
>     (some work needed by RubyGems team)

Right now there are two executables in RubyGems' bin/, gem and  
update_rubygems.

I think I can put update_rubygems inside the gem command too, or  
remove it outright.

This means just one command 'gem' needs to be installed into BINDIR.

> 4. What $LOAD_PATH order should be?
>
>   4-1. by default?
>     [-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .] or
>     [-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, ., GEMs]
>
>    - enable RubyGems by default?
>    - opt-in?

By default, I think:

   [-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .]

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

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

> 5. Where's the global repository for bundled rubygems?
>    Of course RubyForge should be pointed.
>
>   - we need some 'rather official' repository at www.ruby-lang.org,  
> too.
>   - RubyForge plus its mirrors are sufficient.

Could we make gems.ruby-lang.org a CNAME for gems.rubyforge.org?  Or  
vice-versa?

gems.rubyforge.org needs to stay around for backwards compatibility,  
of course.

RubyGems does have support for changing the repository path  
independent of a release built-in.

> 6. What libraries does RubyGems depend on?
>      YAML/Syck, WEBrick, the digest libraries, rbconfig, rdoc, thread,
>      optparse, forwardable, time, openssl, open-uri, uri, net/http,
>      fileutils, zlib, stringio, socket, tempfile, pathname
>
>   - YAML is used for the gem index and could be dropped in favor of
>     marshal.
>   - WEBrick is only used for gem_server and not critical.

Also fileutils, find and test/unit.

> 7. Discussion deadline?
>
>   - vaguely October or so

I should be able to get platform/binary gems feature complete in  
August, since I'm taking an extended vacation.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars