Posting gems to Rubyforge
October 6th, 2009Github aren’t building new gems at the moment as they finalise their move to Rackspace. So what do you do if you’ve got a gem that you would like to make available?
Gemcutter’s the new kid on the block – it works as a set of plugins to the gem command that mean you can simply go `gem push my.gem` and it becomes available to the world. Nice as this is, gemcutter’s still pretty young and is currently hosted off one guy’s S3 account.
So we went back to good old-fashioned Rubyforge. Except, believe it or not, I’d never published to Rubyforge before. And it wasn’t as straightforward as it could have been.
I was using the echoe library to build my gem – which gave me a simple `rake manifest`, `rake release` workflow. All good. When you `rake release` it asks if you want to publish to rubyforge; you say “yes” and go to bed happy.
Or not in my case.
Firstly, you need to actually configure rubyforge. Install the rubyforge gem, then use `rubyforge setup` to put in your username and password. Then use `rubyforge config` to make them stick.
That done, I `rake release`d. And got a “no group_id configured for mygem” error. Eh? Googling seemed no help whatsoever – it was mentioned in a few places but people seemed to have resolved it without actually posting their solutions (or I was being blind).
What you need to do is tell Rubyforge where to put your gem. In our case we already had a project on Rubyforge that the gem could be attached to – so `rubyforge create_package project_name gem_name` did the trick. Otherwise you need to get a project set up to house your gem.
But it still didn’t work. This time complaining about a processor id. I had no idea what I was looking for this time, until I discovered this pastie by Dr Nic. The autogenerated config file (normally in ~/.rubyforge/auto-config.yml) is missing some vital information – namely codes for different processor architectures. I pasted the list into your config file and then tried the `rake release` again. And this time it worked!
processor_ids:
IA64: 6000
AMD-64: 1500
Any: 8000
Sparc: 4000
PPC: 2000
Other: 9999
Alpha: 7000
i386: 1000
UltraSparc: 5000
MIPS: 3000
So for the sake of posterity – and anyone else who gets “no group_id configured for mygem” or “no processor_id configured for mygem” messages, I thought I should let you know how I got there.
October 7th, 2009 at 2:15 am
What does “one guy’s S3 account” have to do with it?
Peepcode is hosted off one guy’s S3 account, as are many other successful websites.
October 7th, 2009 at 2:25 am
You basically just described one of the main reasons why I started Gemcutter. If you’ve got any qualms about the service (besides this about S3), let me know, I’ll be glad to help ease them. :)
October 7th, 2009 at 4:23 am
I’m not in any way slagging off gemcutter – I like it. But it’s young and has a single point of failure.
If Geoffrey Grosenbach, for whatever reason, decides to close his S3 account down then that means I can’t get access to his stuff. Peepcode customers have a dependency on Geoffrey.
If Nick decides to close his S3 account down (or Amazon screws up billing and closes his account or even worse, he gets hit by a bus), it’s not just me that’s affected – anyone who uses this gem (our customers) have a dependency on Nick.
If it was my personal stuff it wouldn’t matter, but it’s not – it’s work stuff . And yes, they can grab the source off Github – but the reason the release was delayed in the first place was because we were relying on Github – so it’s about spreading the load.
(Plus a Rubyforge mirror happens to be available on one of our bandwidth providers, which is nice).
I can see from the mailing list replies that Nick is looking into the mirroring; but it’s not here TODAY and this release was already late.