From: Eric Hodel Date: 2007-10-13T18:40:33+09:00 Subject: 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