July 2008

Don't forget about RubyForge

GitHub has changed the Ruby community. No doubt. Suddenly “everyone” is using Git and contributing has never been easier. However, we’ve also been lazier.

We no longer upload gems to RubyForge or write announcements on our blogs, in stead we use GitHub’s gem server and announces them through Twitter. It’s not enough to subscribe to their blogs, you also have to follow them on Twitter to catch new releases.

The biggest problem, however, is that we no longer use RubyForge’s gem server.

Releases should be centralized

One of the best things about Linux is the package manager. No point of googling for installation instructions when we can simply sudo apt-get install money-generator. Without any hassle you can download and install any application without knowing where it’s really located.

It’s centralized. Not in the way that it only connects to one server, but you have official repositories which are enabled by default. And everything should be in these repositories.

Yes, you can add unofficial repositories, but these should only contain stuff which for some reason can’t be included in the officials. Like development versions.

Ruby also has a package manager: RubyGems. We also have a centralized repository: RubyForge. That’s the place where every single Ruby library should be.

GitHub’s gem server

So GitHub starts a gem server. Should it change anything? No! We should still upload our gems to RubyForge.

I’m not saying that GitHub’s gem server shouldn’t be used. Not at all! It’s a perfect solution if you want to provide development versions without messing with a gem server. Or if you want to distribute your fork.

What I’m trying to say, is that you should’t use any other server than RubyForge for regular releases!

An example

Mash is really cool. Installing it, though, not so cool:

~ $ sudo gem install mash
Successfully installed mash-0.0.3
1 gem installed
Installing ri documentation for mash-0.0.3...
Installing RDoc documentation for mash-0.0.3...
### Wait! I *know* that mash-0.0.6 was released today! Where is it?
### Ah! GitHub!
~ $ sudo gem install mash --source http://gems.github.com/
ERROR:  could not find gem mash locally or in a repository
### Uhm.. Who created this, again?
~ $ open http://github.com
### *searches for "mash"*
~ $ sudo gem install mbleigh-mash --source http://gems.github.com/
Successfully installed mbleigh-mash-0.0.6
1 gem installed
Installing ri documentation for mbleigh-mash-0.0.6...
Installing RDoc documentation for mbleigh-mash-0.0.6... 

Dependencies are hard

When RubyGems installs a gem it expects all the dependencies to be on the same server as the gem itself. It may sounds weird, but that’s how it works. So if I created a gem which depends on “mbleigh-mash” and uploads it to RubyForge, it won’t be installed unless you install “mbleigh-mash” first.

Say goodbye to simple installation; now the users need to learn this pretty command: sudo gem install mbleigh-mash --source http://gems.github.com && sudo gem install my-cool-lib.

(I have nothing against neither Mash nor Michael Bleigh, it’s just a coincidence I picked this as an example.)

Don’t forget about RubyForge

It doesn’t take many minutes to upload a gem to RubyForge, and it’s absolutely worth it. I know it’s tempting to think that a git push is enough, but think about all those hours you have saved by using Ruby! I’m sure you would survive by spending some minutes of them on a complicated form.