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

Gavin Sinclair gsinclair at soyabean.com.au
Sat Sep 11 22:01:23 EDT 2004

On Saturday, September 11, 2004, 7:27:33 PM, Mauricio wrote:

> On Thu, Sep 09, 2004 at 10:01:46PM -0400, Gavin Sinclair wrote:
>> Possible solutions: allow the following:
>>   A) require 'extensions/string', '= 0.3'
>>   B) require_gem 'extensions/string', '= 0.3'
>>   C) give up on such shortcuts

> (B) is somewhat nicer to other repackagers because it's easier to
> grep for.  Additionally, RubyGems' isn't the only way to handle library
> versioning, so IMHO require_gem is clearer.

Actually, I've changed my mind :)  Although require_gem
'extensions/string' is sensible, the same is not true of all gems.
For example:

  require 'diff/lcs/array'                # fine
  require_gem 'diff-lcs/array'            # nonsense

  require 'net/ssh/sftp'                  # fine
  require_gem 'net-ssh/sftp'              # nonsense

It's not worth pursuing a shortcut that applies to only some gems
(even if it's most gems) -- it just looks like a hack then.

A possible alternative is to change the way require_gem works, in line
with what Austin has suggested on ruby-core.  That is, using the
'require' path instead of the gem name.  For instance:

  require_gem 'diff/lcs'            # instead of require_gem 'diff-lcs'

Then you can have:

  require 'diff/lcs'                      # don't care about version and
                                          # want to interoperate

  require_gem 'diff/lcs', '> 1.0.1'       # do care about version

  require_gem 'diff/lcs/array', '> 1.0.1' # hey, shortcuts work too!

That's obviously a pretty fundamental change.  I think there's merit
in it, but I'm not going to pursue it.  It seems pretty clear to me
that when you say "require_gem X", then X should be the _name_ of a


More information about the Rubygems-developers mailing list