Re: Import gem to Ruby 1.9

On Oct 13, 2007, at 02:00 , NAKAMURA, Hiroshi wrote:
> Yukihiro Matsumoto wrote:
> > We are discussing how we call rubygems after the merge.  Possible
> > options are:
> >
> >   (a) just merge; if one wants to load libraries from gems, he needs
> >       to require 'rubygems' first.  very traditional, but introduces
> >       unnecessary normal library/gem'ed library separation.
> >
> >   (b) silently require 'rubygems' in initialization process.   
> rubygems
> >       requires a lot of other libraries, so that memory consumption
> >       might be an issue.
> >
> >   (c) create (or separate) tiny library only for finding gems,  
> and let
> >       it be loaded in the initialization (from prelude.rb).  but no
> >       one knows how easy/difficult to make such a library (yet).
> >
> > How do you think?
>
> I needed to confirm the sense of core team about (c) first.  Sorry not
> posting this to ruby-dev first.  I was waiting ko1 posting about  
> this topic.
>
> Matz, ko1 and akr, do you think that (c) includes gem version control,
> for example 'gem "soap4r", "1.5.5"' ?  Need to confirm the requirement
> of core team first.

Please see my notes in [ruby-core:12644].  If RubyGems itself makes  
improvements in the capabilities of require 'rubygems' it benefits  
all RubyGems users, including those still using Ruby 1.8, so I would  
like to explore making RubyGems lighter as much as possible before  
resorting to a Ruby 1.9-only solution.

> Drbrain, sorry about this confusion.  Core team raised an objection to
> [ruby-core:11803]
> http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-core/11625? 
> 11588-12637+split-mode-vertical
> at this late date.  They think that gem loading feature should be
> enabled by default. (Topic 4-1 arrived to the conclusion (a) above.)
> OK, I know it's better than not discussed before imported.  Core team
> should have been busy on M17N I think.

I think that loading rubygems by default is acceptable.  Since it is  
for Ruby 1.9, such a change is ok.

> I may write my opinion later but basically the intent of RubyGems team
> must come first.  We won't be able to maintain rubygems without
> cooperation by RubyGems team.

I am interested in making RubyGems work well for everybody, and will  
certainly consider any issues the core team raises.

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