[Rubygems-developers] Release 0.8.0? (Was: Rubygems update script updated on rubyforge)

Gavin Sinclair gsinclair at soyabean.com.au
Thu Sep 9 22:01:46 EDT 2004

> On Sep 9, 2004, at 9:11 PM, Gavin Sinclair wrote:
>>> OK.  The fix is in.  I successfully installed every gem in the
>>> repository (newest versions) via a script with no errors!
>>> Time to release? :)
>>> Chad
>> I don't believe 'require' is properly implemented.
>>   $ irb --simple-prompt
>>>> require 'rubygems'
>>   => true
>>>> require 'rake', '< 0.5'
>>   ArgumentError: wrong number of arguments (2 for 1)
>>           from (irb):2:in `require'
>>           from (irb):2
> The mult-argument require hack hasn't been implemented (and probably
> won't be).  Rich and I were chatting about it yesterday.  If you're
> going to use a version requirement, it's not compatible with
> non-rubygems' require, so you've blown the compatibility angle.  So,
> you might as well use require_gem.  Agreed?

Yes, it's not backwards compatible; fair enough.  But now there's no
versioned shortcut, which is a niggling annoyance.  And worse, it's

  require 'rubygems'

    # If I want 'dev-utils/debug', no matter the version, I'm happy.
  require 'dev-utils/debug'

    # If I want 'extensions/string' version 0.3, I'm not happy.
  require_gem 'extensions'
  require 'extensions/string'

Possible solutions: allow the following:

  A) require 'extensions/string', '= 0.3'

  B) require_gem 'extensions/string', '= 0.3'

  C) give up on such shortcuts

About (A).  You guys don't like it because it allows (but doesn't enforce)
a backwards incompatibility.  I don't mind it because the incompatibility
is obvious and optional.  You would obviously only write such code if you
had successfully loaded 'rubygems'.

About (B).  Rich doesn't like it because it blends namespaces: the gem
name with a path inside the gem.  I counter that this blending is mostly
transparent (i.e. require_gem 'X/Y' almost always equates conceptually to
require 'X/Y'; and it _always_ equates technically, by definition). 
Furthermore, there will never be any other meaning for require_gem 'X/Y'
-- nobody has a taste for hierachical gems -- and its meaning as a
shortcut is perfectly obvious to me.

About (C).  We have made, and are continuing to make, a lot of effort to
make RubyGems as transparent as possible.  Not doing anything about this
undermines such efforts to a small but noticable extent.  One of the
transparencies is the 'autorequire', which is terrific.  But not all gems
have an 'autorequire'.  It is inconsistent to cater to one category of
gems but not the other.

Put simply, we would not accept having to do this, because as programmers
we abhor duplication.

  require_gem 'rake'
  require 'rake'

So why should I have to do this?

  require_gem 'extensions'
  require 'extensions/string'

In the second case, the duplication is not complete, but it's obvious
enough that a solution should be found.

The only actual solutions I can think of are (A) and (B) above.  On
balance, I prefer (B), because it allows us to make this rule clear:

  If you want to specify a version constraint, use require_gem.

Everything then becomes consistent.  The following code works:

  require 'rubygems'
  require 'dev-utils/debug'
  require_gem 'extensions/string', '= 0.3'

require_gem still looks ugly, but that's the price we pay for not allowing
version constraints with require.

What say you?


More information about the Rubygems-developers mailing list