Because we needed it! And needed it badly.

No. It is based on the same idea, but the code was written from scratch (initially) at RubyConf 2003.

Doesn’t this open a huge security hole? How can I trust the Gems which are automatically downloaded from the net?

The same way you can trust all other code you install. (I.e. ultimately, you can’t.) : Gems are not automatically downloaded from the ‘net, they are manually downloaded from the ’net. It’s essentially the same as grabbing a tarball from the RAA or RubyForge, but easier. The “automatic dependency” resolution prompts you for confirmation before installing anything.

It’d be nice to package code as a Gem, and then have it easily portable to many packaging systems (e.g. manual, RubyGems, dpkg/apt-get and other distro specific packaging). A quick glance at RubyGems suggests that installation of a package as a Gem requires all of its dependencies to be gems also (due to require_gem). Thoughts on this?

It would not be too difficult to create a convertor to auto-generate dpkg or rpm files out of gems. It has been on the TODO list since day 1, but it hasn’t yet made it to the top of anyone’s priority list. Anyone who would like to do this for one or more packaging systems is more than welcome!

From Eivind Eklund:
p((((. I believe this is undoable inside the required structures for most other packaging systems (based on the Filesystem Hierarchy Standard). FreeBSD and Debian at least requires following a structure that is different from and not compatible with one directory per gem. I believe the same requirements exists for other package repositories (Fedora, NetBSD, OpenBSD, at least), but have not looked at them in detail recently enough to remember with certainity. Automatic repackaging for RPA is undoable because RPA requires that the packages can be re-exported in the formats required by other packaging systems. (Oh, and I would LOVE to be proved wrong on this.)

Is it possible (or is there a plan) to use RubyGems with AllInOneRuby or RubyScript2Exe?

It would seem so. Erik has been hard at work adding RubyGems support for both of those tools, and the current versions have both been successfully used with some gems.

RubyGems no longer uses YAML for metadata. `gem help generate_index` shows the structure of a RubyGems source.

http://rubygems.org no longer generates a yaml index, but the Marshal full index is still generated nightly.

Here are a couple of resources:

• RubyConf 2004 Presentation

• RubyGems chapter in Pickaxe II