From: Hal Fulton <hal9000@...>
Date: 2004-03-22T04:16:21+09:00
Subject: Re: rubygems - did install went ok?

Richard Kilmer wrote:
> 
> On Mar 21, 2004, at 9:16 AM, Chad Fowler wrote:
> 
>>> I was also telling Chad and/or Rich that if gems become a standard, I
>>> would like to see require_gem simply go away.
>>>
>>> 'require' would be modified so that it looked for a gem before anything
>>> else. This would also make "require 'rubygems'" unnecessary.
>>>
>>>
>>
>> That might be a good thing to do eventually, but I think it's good to 
>> keep things obviously separate while we stabilize RubyGems.  We have 
>> always said that RubyGems doesn't replace the 'require' facility, but 
>> it might be possible to augment that facility in the way that you 
>> Jason Creighton have proposed.
> 
> 
> The only issue here is that 'require' does not modify the $LOAD_PATH 
> like require_gem does.  Changing the meaning of 'require' would 
> ultimately have to be something Matz decides, not us.  Once RubyGems 
> system (especially the 'runtime' aspect of it) gets stable we will then 
> present it to Matz likely as an RCR and then figure out the final way it 
> will integrated into the Ruby runtime (if accepted).

Certainly. I was speaking of a more distant future when the gem spec was
stable and gems were common.

And obviously it would be Matz's decision. All I'm saying is that
   1. In the long run, we shouldn't have to do 'require "gems"' in
      (virtually) every single Ruby program
   2. The additional burden of a gem_require seems rather a nuisance
      to me. I grant you the semantics are different from require. But
      to me it is as if we had require_rb, require_so, require_dll
      (instead of simply require).

Anyway, my comments were meant to be highly conditional:
   - if/when gems stabilize
   - when/if gems are common as dirt
   - when/if someone suggests such an idea and Matz approves it

Cheers,
Hal