Re: Import gem to Ruby 1.9

On 7/18/07, NAKAMURA, Hiroshi <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Thanks for your comments, TRANS, Ryan and Eric.  Good to know you all
> are positive about including RubyGems.
>
> TRANS and others, what libraries should be unbundled is the next (or the
>  next) topic.  Wait for a while.
>
> Matz, Syouhei, there seems to be no barrier to add RubyGems into
> ruby/1.9.1 so far.  Don't you disagree we can continue the discussion
> about bundling RubyGems with Ruby/1.9.1?
>
> Eric Hodel wrote:
> >> > RubyGems is still missing one key feature, the ability to handle
> >> > platform-specific gems.  There may be a few other minor features that
> >> > are missing, but I don't think RubyGems is ready for inclusion until
> >> then.
> >>
> >> Are you and RubyGems maintainers negative to include RubyGems in
> >> ruby/1.9.1 ?
> >
> > No, we'd really, really like RubyGems to be in core, but I'd really,
> > really like to get the platform-specific gem handling working before it
> > is in core.
> >
> > (The C stub to make ruby -r work with an in-core RubyGems should be easy
> > to implement.)
> >
> > I'll have some free time coming up in August, so I may be able to get to
> > it then.
>
> Thanks for your work always about ruby.
>
> In above which are you planning to implement 'platform-specific gem
> handling' or 'C stub to make ruby -r work'?  In the case of the latter
> topic, ruby itself may be able to help it with adding common
> 'require-hook', if someone can design such a feature.  We should do
> things step by step so some features like above can be delayed to 1.9.2
> though.
>

A built-in require hook would be excellent.  I'm sure I'm going to
raise some feathers here but if we're going to include RubyGems in the
distribution, what is the general feeling about just including the
RubyGems LOAD_PATH semantics as part of how #require naturally works?
That would mean either of two things:  1) #require is enhanced in C to
do the RubyGems logic of looking in the installed gems and adding to
the LOAD_PATH + requiring on match or 2) require 'rubygems' by
default.

I'm not necessarily arguing for this.  Just raising the idea.

>         /       /       /
>
> At first, let's list issues about bundling RubyGems to ruby/1.9.1.
>
> 1. Is platform-specific gem handling needed?
>

We need to at least clean up the way it's implemented now.  It's not
so much a few feature as an annoyance that needs to be fixed.

> 2. Does RubyGems need some 'require-hook' feature to be added to
>    ruby/1.9.1?  What's the requirements?
>    - hooks -r options
>

The problem with -r is that it doesn't delegate to #require.  It runs
the underlying C function with #require delegates to.  So it's
impossible in Ruby code to override the behavior of -r.

> 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? (I mean 'ruby -rgem -e update gemname')
>

I think we need gem and gem_server at a minimum.  gemwhich would
actually be a nice general-purpose Ruby utility.  It could be renamed
rubywhich or rbwhich and installed.

> 4. What $LOAD_PATH order should be?
>   4-1. by default?
>     [RUBYLIBDIR, SITEDIR]
>   4-2. after requiring rubygems?
>     [GEMs, RUBYLIBDIR, SITEDIR] or
>     [RUBYLIBDIR, GEMs, SITEDIR] or
>     [RUBYLIBDIR, SITEDIR, GEMs]
>
> 5. Where's the global repository for bundled rubygems?
>    Of course RubyForge should be pointed.  Do we need some
>    'rather official' repository at www.ruby-lang.org, too?
>

Personally I think RubyForge plus its mirrors are sufficient.  We
could do a cname for gems.ruby-lang.org perhaps?  RubyForge is run by
Ruby Central, so you could consider it to be 'rather official' already
I suppose.

> 6. What libraries does RubyGems depend on?
>    - existing bundled libraries
>    - new libraries
>      I forgot to mention that rake should be added to 1.9.1, too.
>

Off the top of the head, YAML/Syck, Webrick, the digest libraries,
rbconfig, rdoc, thread, optparse, forwardable, time, openssl,
open-uri, uri, net/http, fileutils, zlib, stringio, socket, tempfile,
pathname


Chad