Gemcutter: A New Gem Hosting Repository Taking Aim At RubyForge and GitHub
Gemcutter is a new gem hosting repository that aims to replace RubyForge as the canonical repository for gems. The project has been around for a couple of months, but Thoughtbot recently announced they're helping out with a forthcoming redesign of the site.
As part of the plan to get everyone using it as their main gem repository, Gemcutter has already imported all of the gems that were on RubyForge - meaning there are over 5000 gems on there already.
After installing Gemcutter (with gem install gemcutter), consumers of gems just need one command to set Gemcutter up as their primary source:
gem tumble
As a publisher, you can just use the git-esque "gem push" command to release a new version of your gem.
gem push yourgem-0.0.1.gem
If you had a gem on Rubyforge and it has been migrated across, then there's a simple procedure for claiming it.
Other than ease of publishing, other benefits of Gemcutter include the way it sidesteps the confusion surrounding Github's naming policy for gems (i.e. prepending the Github username to the gem), and that it provides easy, obvious access to project-pages for the gems.
When I first came accross Thoughtbot's post on the Giant Robots blog, I originally thought that Gemcutter belonged to them, and great as Thoughtbot are, I was still a little bit worried about a single company taking ownership of a large slice of Ruby-community real-estate. Nick Quaranto, the owner of the Gemcutter Github repo (and intern at Thoughtbot) has assured me, though, that it belongs to the community first and foremost.
August 20, 2009 at 2:39 pm
I don't mean to be rude, but what exactly is the superiority of this over Rubyforge? OK, there are a few extra scripts. Patch RubyGems, problem solved. This seems to just duplicate the functionality of RubyForge without all the fancy features...?
Even worse, if someone pushes my gem that I have on Github to gemcutter before I do, they now own it. I guess that's a problem on Rubyforge, too, but at least that's manually reviewed (do they still do that?).
August 20, 2009 at 2:57 pm
Jeremy: first off, it's an open source effort done totally in Ruby, so if there's something that you want in the site, that can now happen easier. The point was to make a gem host without all of the extra stuff that RubyForge offered. Other sites do a much better job of the other features now (mailing lists, source code hosting, bug tracking, etc). By limiting the scope of what the site can do, I feel we've created a better service that the community can enjoy.
As for reviewing gems on RubyForge, I'm not aware of how that works, but they do auto-approve new gems now. On Gemcutter, the site currently pulls down the latest gems from RubyForge on a nightly basis, and I plan to do the same with GitHub gems as well eventually.
August 20, 2009 at 2:59 pm
Regarding the review stage on RubyForge, I recall reading something in the last month or so that it's all now automated.. I could be wrong.
August 20, 2009 at 3:42 pm
Sorry, but, I think rubyforge is going to persist longer than this will.
The fact is, github has not been nearly as stable as rubyforge, and there's absolutely no reason to believe that a company can afford to support such a thing in all situations.
What really upsets me about this kind of thing is that support / money could have been sent to rubyforge, but I get the feeling that this wasn't even considered.
August 20, 2009 at 4:09 pm
What really upsets me about this kind of thing is that support / money could have been sent to rubyforge, but I get the feeling that this wasn't even considered.
That's a variant of the "Why start a new project instead of helping an existing one?" argument that crops up often online. It's easier and often more effective to create your own new projects than help existing ones that are run by people who might disagree with you or otherwise not let you improve it in ways they don't like.
I believe RAA predated RubyForge and a similar argument could have been made then. git.or.cz and Gitorious (I believe) existed before GitHub, etc, etc.
August 20, 2009 at 5:35 pm
"I get the feeling that this wasn't even considered"
As a rubyist who actively carries over 100 installed gems, having 3 regular sources is a real pain in the butt.
August 20, 2009 at 5:38 pm
Also, I'd rather a not for profit was in control. I don't want to find a failing company suddenly starts charging on what has become "the" canonical source for gems. That would kill more than my chi.
August 20, 2009 at 5:38 pm
I am excited about this for the simple reason that their focus is on doing one thing and doing it well. Anyone who has actually used rubyforge (for anything other than indirect usage with a 'gem install') will know that RubyForge is a total POS. The interface is a mess, it has seen almost zero change or improvement in years, and it does everything it does badly (except simple hosting of gem files).
Additionally, publishing and hosting on RubyForge was so painful that developers have been getting lazy and not even publishing 'official' releases on RubyForge anymore. Choosing to rely instead on bleeding edge versions of gems built from GitHub repo's. This was unhealthy and RubyForge did nothing to alleviate the problem.
The only thing that surprises me is that GitHub made no moves at all to become the canonical source for gems.
I predict that if they play their cards right, gemcutter will be THE source for official releases of gems in a year. Remember how fast we all switched to Git? And that was a much harder transition.
PS - GemCutter guys. Don't make us rely on the gemcutter gem to set things up. Give us a standard gem source add command as well. Also, incorporating information from isitruby19 and isitjruby websites would be helpful.
August 20, 2009 at 5:43 pm
I had the thought the other day "rubyforge is a poor fit for ruby projects" -- it just feels awkward somehow. Thankfully github has come around with a much better fit, maybe this will also help it die. RAA should die, too, now that I think about it.
@raggi: maybe gems should be specified by more than just name--like url+name? That would be nice.
gem.dependency ['github', 'some_gem']
thoughts?
August 20, 2009 at 5:47 pm
We already have to deal with that way too much roger, since github came along. Now there's an above average disparity between gem names and the actual libs they provide. Furthermore, when github is the only canonical source for a particular gem, which is becoming *very* common in the sinatra subculture, having github down can be a massive pain.
That's a commercial problem. In my entire time in ruby, rubyforge has been down less than a handful of times. Maybe that's down to the way it's run, or average load, or whatever, but a language centric service to be used by millions of people on a weekly basis really needs to be both commercially independent and very stable. To date, only Rubyforge has delivered this.
August 20, 2009 at 5:48 pm
Props to Tom Copeland, who deserves it, bigtime.
August 20, 2009 at 5:57 pm
And there's a big big point here.
If you're *really* trying to make *my* life easier, and not looking for *profit* you could sync both ways.
The rubyforge gem makes this trivial, and is older than most of us have been doing ruby.
August 20, 2009 at 7:00 pm
Had an interesting chat with defunkt on this topic. From what he said, there are talks being started up between Tom and the rest of the rubygems team, to talk about moving over the main gems service to a gemcutter base.
If this happens, and gems.rubyforge.org is moved, or the gemcutter source is added by default, then I will have much less of a problem with this whole area.
If everything gets sync'd up accordingly, then I welcome this facelift to the main ruby software repositories.
August 21, 2009 at 5:45 am
Thanks to Sun for the hardware donations. RubyForge is running on an X4200 M2 that they gave us... good stuff.
August 21, 2009 at 6:15 am
And when I say "Sun", I mean specifically "Tim Bray".
August 21, 2009 at 9:55 am
"That's a variant of the "Why start a new project instead of helping an existing one?" argument that crops up often online. It's easier and often more effective to create your own new projects than help existing ones that are run by people who might disagree with you or otherwise not let you improve it in ways they don't like."
yeah, but if it's for doing the almost same thing; that just sucks.
honestly, there was a time in here (ruby in general, this website) when things seemed to be innovative, but we end up with the "i almost done the same stuff, but i got reasons to have lost my time because mine is better".
it is not to your project, but it is disappointing.
August 21, 2009 at 12:55 pm
GR: You don't need to use the Gemcutter gem in order to make it your primary Gem source, all that `gem tumble` does is add http://gemcutter.org as the first source in the list while keeping the rest. There doesn't seem to be a way to do this now with `gem sources` short of editing your ~/.gemrc, so `gem tumble` is there to make this easier.
August 21, 2009 at 2:48 pm
Nick: thanks for clearing that up. I did think that it was a bit of a paradoxical requirement to have to install a gem (from Rubyforge) to be able to use Gemcutter! :)
August 21, 2009 at 5:23 pm
I love the idea of Gemcutter - a simple gem host which doesn't try to do everything.
However, I want to keep my gems a single "gem install" command away from anyone receiving them. Therefore I will continue to host the gems on RubyForge. I think it's worth the extra effort on the publisher's side to present a clean, simple installation experience on the consumer's side.
That said, if RubyForge adopts Gemcutter as the official gem repo (so it is a single "gem install" away) then that would be awesome!
August 23, 2009 at 6:31 am
Should have at least kept the rails-marketing-style kind of names, like gemcuttr or som', maybe "gemkillr" would've been more relevant.
August 23, 2009 at 6:33 am
But in the end the saddest seem that rails people seem more focused on reinventing the (their own wheel) wheel rather than than putting stuff in production.