From: Jim Weirich <jim@...>
Date: 2006-05-24T02:09:51+09:00
Subject: RAA, gems, and RubyForge (was Re: User Account Setup - Multi

Others have given good answers.  I'll just make a few additions ...

John Gabriele wrote:

> 1. Is there a central repository of gems somewhere? That is, when you
> run "gem install -r ...", where does it get the gems from?

As others have mentioned, the gems are supplied from RubyForge.  In 
addition, you can select an althernative source by using the --source 
option.  I often put beta versions of my software on my own site and 
people can grab it with:

   gem install rake --source http://onestepback.org/betagems

It's easy to create and maintain an alternative gem server.

> 3. With the current RubyGems 0.8.11, should we do
> 
> require 'rubygems'
> require_gem 'foo'
> 
> or
> 
> require 'rubygems'
> require 'foo'

Always use the second unless you need a particular version of a gem.

I recommend NEVER putting a require_gem in your normal library code 
(mainly because you don't want to have version dependencies scattered 
throughout your code base).  Version dependencies should be gathered 
into a single location and made configurable by the end user (e.g. 
something similar to what Rails does with its environment file).

The next version of RubyGems will have a simple "gem" directive that is 
similar to what require_gem does now, but with less surprizing 
semantics.  But the recommendation in the above paragraph will still 
apply.

> 4. For users (both devs creating gems, and folks installing and using
> them), what's expected to change when RubyGems 0.9.0 gets released?
> "require_gem"?

The next version of RubyGems will have:

(1) Incremental downloads of the RubyForge index.  You will only need to 
download the entire thing if you are too far out of date.

(2) Support for the new "gem" directive ("require_gem" will still work, 
we just won't recommend it anymore).

(3) Support for supplying static configuration data with an installed 
gem, and mechanisms for getting that data.  This will make it easier for 
developers to repackage a gem as an alternative OS specific package 
(e.g. RPMs and Debian packages).

(1) and (2) are done and ready to go.  We are still ironing out some 
details on (3).

Looking even farther out, we intend to unify the way RubyGems treats 
local and remote gems (for example, installing a local gem does not 
check dependencies).  We will also support resolving dependencies across 
different servers.

Thanks for asking.

--
-- Jim Weirich

-- 
Posted via http://www.ruby-forum.com/.