From: "Mauricio Fernández" <mfp@...>
Date: 2005-09-22T21:11:15+09:00
Subject: Re: RubyGems TODO

On Thu, Sep 22, 2005 at 08:50:48PM +0900, David A. Black wrote:
> >In practical terms, I'd suggest that (7) become one of the following:
> >
> >* dump require_gem and auto_require, add the ability to demand a specific
> > version to Kernel#require, in such a way that it is possible to ignore 
> > such
> > version requirement if the distributor uses another system (for instance, 
> > it
> > is possible to resolve this semi-statically).
> 
> With RubyGems as part of the Ruby distribution, "another system" will
> mean "something other than Ruby."  No, I don't mean that RubyGems is
> perfect or above criticism (etc. etc.).  But when we start talking
> about changing the way Ruby method calls work, so that someone

Nobody is talking about changing the way Ruby method calls work. Read
below.

> distributing Ruby can do battle with Ruby, that starts to seem
> excessive and counter-productive.

RubyGems will change the way Ruby works if merged into HEAD.
What we're discussing is which changes are needed, and how to proceed.

In particular, feel free to comment on the relative merits of 
   require_gem 'X', '1.2'   # maybe use_gem ?
   require 'y'

vs.

   require 'y', '1.2'

Something similar to the 2nd one is what I tried to convey in the item you
commented on.

> It would make more sense, I think, to leave this kind of parser and
> language-behavior modification to the people who consider themselves

?? Who said anything about changing the parser or the language? If
you've being confused by my reference to semi-static methods to
resolve load paths, just ignore it for now. I'll try to write on that
later. For now, I'll just say that it doesn't involve any language
change, and actually, it involves fewer changes in the "runtime" (like
Kernel#require redefinitions) than RubyGems is doing (or none at all,
depending on how it's done).

-- 
Mauricio Fernandez