From: Gavin Sinclair <gsinclair@...>
Date: 2004-06-25T06:52:42+09:00
Subject: Re: rubygems thoughts

On Friday, June 25, 2004, 2:00:11 AM, Jim wrote:

> (1) Gems can be installed with a "stub" in the standard library location.
> This stub requires rubygems, then requires your package with the proper
> version, providing a transparent access layer for gems.  Stubs are now
> installed by default (controlled by an option on the gem command line).

Let me make this really clear with an example session:

  $ ruby -r ruby-doom -e ''
  /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:28:in `require_gem':  (LoadError)
  Could not find RubyGem ruby-doom (0.0.0)
          from /usr/local/lib/ruby/site_ruby/1.8/ruby-doom.rb:11

  $ gem -Ri ruby-doom
  Attempting remote installation of 'ruby-doom'
  Successfully installed ruby-doom-0.8

  $ ruby -r ruby-doom -e ''

  $

  
> (2) One of the benefits of rubygems is the ability to specify some version
> control over what gems get used with your library/application.  If you
> wish to take advantage of version control, then you necessarily become
> dependent on the gems.

> We are still evolving the "Best Practices" for gems, but I suspect that a
> lot of projects will collect their "require_gems" in one area for better
> version control.  (I don't want to say I want version ">= 2.1" in more
> than one place!)  So I suspect require_gem with version specs to become
> centralized and normal requires to continue to appear in whatever file
> needs them.

> Once the version control is centralized, it is easy to make it optional.
> For example, just bury the require_gems in a rescue block and if it fails,
> continue normally.

That's a really good win-win approach!  This means the code will
happily run whether rubygems is installed or not, and it's easy to
maintain.  Not only that, but it captures all the dependencies in one
place, so you can document (for non-RubyGems users) what other
packages they'll need installed.

Now, can this be taken a step further?  Those dependencies are kept in
the gem spec anyway; why duplicate them in code?  Is there some way we
can reuse the info in that spec?  Is that something worth pursuing?

>> Point two, for gems to be really useful pretty much all the common
>> libraries at least need to be gems. That's normal, and what I'd call
>> critical mass for a packaging system.

Yeah, at some point we (the developers) should have a "working bee" to
create as many gems as possible :)

Gavin