Others have given good answers. I’ll just make a few additions …
John G. wrote:
- 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.
- 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.
- 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 W.