On Jul 17, 2007, at 01:26, NAKAMURA, Hiroshi wrote:
> Hi Eric,
> Eric Hodel wrote:
> >> Matz plans to import gem into Ruby 1.9.  Does anyone has any
> >> comment to this?
> >>
> >> - possibility/difficulty to import
> >
> > RubyGems uses many features of Ruby, so 1.9's libraries need to be
> > fairly stable in order to continue working.
>
> >> - compatibility
> >> - and other problems
> >
> > 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.

> I have a plan to propose unbundling some libraries such as soap4r, tk,
> webrick, json, etc.  Maintainer-less libraries such as yaml should be
> unbundled, too (bear in mind that I'm talking about ruby/1.9).  It can
> be a gem when RubyGems is bundled in MRI.  It can be a package of
> another packaging system(deb, rpm, etc.), too.  Users will use  
> favorite
> packaging system then.

I'd like to see this too.

> > Also, RubyGems can make releases faster than Ruby can, so it should
> > still be possible to upgrade RubyGems to never versions  
> independent of
> > Ruby.
>
> Do you mean RubyGems can be a gem?  Looks smart.

Currently RubyGems updates come as a gem, but they get installed into  
site_ruby.

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