Re: Import gem to Ruby 1.9

On Sep 30, 2007, at 22:56 , NAKAMURA, Hiroshi wrote:
> It's October, the deadline.  We need to go ahead.
> NAKAMURA, Hiroshi wrote:
> > 1. Is platform-specific gem handling needed in ruby/1.9.1?
> >
> >   - Is binary gem support needed in ruby/1.9.1?
> >     If no one has any objection, it's up to RubyGems team.
>
> drbrain, would you please tell me how it goes on?  Incorporating
> 'platform-specific gem handling' feature to ruby/1.9 is up to  
> RubyGems team.

The platform-specific gem handling feature is done, barring potential  
minor changes in the upcoming week or two.  I expect to release a  
beta of RubyGems this week, and an official release next week.

This would not hold up including RubyGems in 1.9, as I could roll any  
additional changes in as necessary.

All tests pass on 1.9 except for one, which is caused by a minor 1.9  
bug.  I will email separately about it.

> > 2. Does RubyGems need some 'require-hook' feature to be added to
> >    ruby/1.9.1?  What's the requirements?
> >
> >   - just bundle RubyGems with ruby as one of a packaging system.
> >     so hooking -r options as same as Kernel#require is needed.
> >   - Nobu, I heard that you have once designed this feature halfly.
> >     Is there anything you can share with us?
> >   - I was hoping we could use rb_funcall to invoke a  
> Kernel#require in
> >     require_libraries() rather than calling the C rb_require  
> directly.
> >     Is this possible?
>
>
> As the result of long (and sparse :-) discussion on ruby-dev,  
> r13580 did
> the change.  The last one of the above list.  Nobu and I are still
> talking about generic 'require-hook' feature to avoid ad-hoc
> Kernel#require rewriting so any comments are welcome about this.
> Anyway, go ahead and let's bundle RubyGems into ruby/1.9.
>
> drbrain, would you please check if r13580 is enough for RubyGems and
> tell us the result?

Ok.  I will do this tonight (Pacific Time).

> > 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
> >
> >   - just one command 'gem' to be installed into BINDIR.
> >   - is there anyone who thinks nothing should be installed?
>
> Let's bundle just one command 'gem'.

Yes.  This is the only command needed.

> > 4. What $LOAD_PATH order should be?
> >
> >   4-1. by default
> >     [-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .]
> >    - RubyGems is not enabled without 'rubygems' library required.
> >
> >   4-2. after requiring rubygems
> >     [-I, ENV_RUBYLIB, GEMs, SITELIBDIR, RUBYLIBDIR, .]
> >    - it's up to RubyGems team because it's opt-in feature.
>
> No objections raised.

Great.

> > 5. Where's the global repository for bundled rubygems?
> >
> >   - of course RubyForge should be pointed.
> >   - prepare gems.ruby-lang.org and add it as a default remote  
> source of
> >     RubyGems?
> >   - remote sources ordering support of RubyGems (by RubyGems team.)
> >   - we need some 'rather official' repository at gems.ruby-lang.org.
> >   - no, RubyForge plus its mirrors are sufficient.
>
> I think we are getting a consensus that we need some official  
> repository
> at gems.ruby-lang.org.  Hmm.  What is different from general gems?
>
> I think that an official gem should be;
>   * of course the gem author maintains bugfixes etc. but,
>   * ruby maintainer (matz, ko1 for ruby/1.9) should have final  
> approval
>     for updating gems.
>
> Right?  Tell me what did you think.

I think this is a good policy.

> And we need to discuss about gem signing and trustness control of
> official gem.  Needed?  Secure?  Operation workable?  etc.

RubyGems has the ability to sign and verify downloaded gems against  
their signatures, and to generate keys for signing gems.  I only know  
the basics of how to use these features, though.

Currently it is up to RubyGems users to enable verification of remote  
gems.  By default it does not verify the integrity of the gem.

> > 6. What libraries does RubyGems depend on?
> >      YAML/Syck, WEBrick, the digest libraries, rbconfig, rdoc,  
> thread,
> >      optparse, forwardable, time, open-uri, uri, net/http,  
> fileutils,
> >      zlib, stringio, socket, tempfile, pathname, test/unit
> >
> >   - 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.
> >   - Dependency to openssl is a must?
>
> Matz said that he can be the chief maintainer of yaml.rb and syck for
> ruby/1.9.  So the dependency to YAML is not matter now.  Now it's  
> up to
> RubyGems team.

RubyGems now has both a Marshal and YAML index, but will be  
publishing both versions in case the Marshal format changes.  Also,  
YAML will be needed for backwards compatibility with alternate  
repositories that don't yet build a Marshal index.

Currently 1.8 and 1.9 use the same Marshal version, but I don't know  
if that is guaranteed, and there doesn't seem to be a way to build  
multiple Marshal indexes without multiple ruby interpreters.

(This addition of the Marshal index was made primarily for memory  
usage reasons.  A full update of the Marshal index uses about 1/3 the  
memory of a full update of the YAML index.)

There may be a few gems in YAML archive format, but I believe that  
nobody will install those, they are very old.

The ~/.gemrc configuration file is in YAML, but it would be easy to  
parse without YAML.

> > 7. Discussion deadline?
> >
> >   - vaguely October or so
>
> End of October, I hope.

By second week of October, I hope.

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