Re: Import gem to Ruby 1.9

On Oct 15, 2007, at 07:14 , NAKAMURA, Hiroshi wrote:
> Eric Hodel wrote:
>>> Definitely.  I want to make sure what they call 'tiny library  
>>> only for finding gems'.  If it means 'RubyGems minus gem  
>>> command', 0.9.4.5 should be enough though I've not yet checked  
>>> it.  If not?
>>
>> Ok.  Please keep me up to date on this.  If 0.9.4.5 is not good  
>> enough I can explore making it even lighter.
>
> Following is my opinion about enabling rubygems by default.  I  
> posted it to ruby-dev at [ruby-dev:32061].  It's an awkward  
> translation of mine.
>
> 	/	/	/
>
> I don't get response from core team to [ruby-core:12643] so I don't  
> know what core team calls 'tiny library only for finding gems'.   
> Here're my reason for objecting to enable rubygems by default.
>
> 1. If 'tiny library only for finding gems' includes replacing
> Kernel.require and Kernel.gem method (everything) with diet version.
>
> 1-1. RubyGems includes packaging, deployment and feature loading
> systems.  I don't think it's bad and it's useful in fact.  But if  
> we let it be an 'official Ruby language specification' by enabling  
> it by
> default, it's not always a good thing.  For example;
>
> 1-1-1. It's said that as a packaging and deployment system it  
> interacts badly with some other existing packaging system.  I heard  
> about it from an official Ruby package maintainer of Debian.  I  
> know almost nothing about actual problem but it should not be too  
> late to enable rubygems by default, after bundling rubygems and  
> seeing how it goes.

We've found that making RubyGems work with other package systems  
difficult.  Each one has slightly different requirements for how  
things should work.  Making one system happy makes another unhappy.

I know that FreeBSD integrates with RubyGems and the `gem` tool, and  
there haven't been any discussions between the RubyGems and FreeBSD  
people.

If a third party packaging system wants to repackage a gem, it is  
easy, the gem format is tar file with a .tar.gz inside.

> 1-1-2. As a feature loading system, letting 'multiple versions  
> aware feature loading' be an official Ruby language specification  
> imposes too much restriction to unborn feature loading systems.

How so?  Or do you mean vs. other possible multiple version aware  
feature loading systems.

> 1-2. Is it possible to call it's not an official Ruby language spec  
> even if it's enabled by default?

I think not.

> 2. If 'tiny library only for finding gems' only includes replacing  
> Kernel.require (does not include version control feature of  
> RubyGems). This means that we bundle RubyGems as the packaging and  
> deployment system of ruby but do not accept it as a feature loading  
> system as is.
>
> 2-1. We should not bundle a library this way.  When we think it's  
> good thing, we should go RubyGems list at first and propose the  
> change.
>
> 2-2. Anyway, granting that RubyGems team accepts this proposal,  
> it's too late for ruby/1.9.1.  From 1.9.2 at best I think.
>
> /	/	/
>
> Though I didn't write it to ruby-dev, I don't think 2 is acceptable  
> for RubyGems team.  Gem.activate with version constraints +  
> dependency control by gem command with .gemspec should be a key  
> advantage feature of RubyGems I think.  Kernel.require and  
> Kernel.gem both depends Gem.activate.
>
> It's still ongoing topic on ruby-dev.  I'm waiting for some  
> thoughts on this topic.


On IRC last night, matz, Koichi, akr and myself decided that RubyGems  
would be imported into trunk, but without require 'rubygems' by  
default.  (Correct me if I am wrong.)

We didn't make a plan for when/how this would happen.

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