----- 
permalink: where-does-your-ruby-code-live
filters_pre: 
- redcloth
title: Where does your Ruby code live?
comments: 
- :date: 
  :author: murphee
  :url: http://jroller.com/page/murphee
  :id: 450
  :body: |-
    I'd say the best way is to 
     - slap your project on Github 
     - then: sign up for Rubyforge (projects usually take a day or two to be approved, at least that used to be the case)
    
    Use Ryan Davis' hoe to manage your project's rake file. It configures your rake file with a task to push a new release to Rubyforge. 
    Voila: done. 
    You get the best of both worlds: github's magic and the benefits of RubyGems. 
    Github also offers you the option to easily offer experimental Gems, eg. if you fork a project, change something with it: you can instantly install that as a gem as well (although you have to add github as source to Gems). Ain't no easier way to distribute a forked version of an existing gem. 
    
    As for that rant you linked to (about Github not being profitable)... well, Github consists of 3 fulltime employees and has made them shitloads of money in the few months it's been around. 
    Eg. see this interview with Tom Preston-Werner:
    http://www.infoq.com/interviews/preston-werner-powerset-github-ruby
    Sure - doesn't mean it'll stick around forever... but the benefit of Git is that you always have the full history of the project on your local disk - even if Github goes away this second. Try getting that with CVS/SVN at any other hoster, where you have to manually do regular snapshots of the history (if the hoster even offers that). 
    So, even if Github might become history at some point, it's still easy to continue by just moving your git repository to, say, Rubyforge's git servers. Github's remarkably free of lock-in, at least when it comes to data. 
    
    PS: InfoQ covered this problem some time ago:
    http://www.infoq.com/news/2008/08/gems-from-rubyforge-and-github
- :date: 
  :author: Fabio Cevasco
  :url: http://www.h3rald.com
  :id: 473
  :body: |-
    So I guess the best solution – for now – is to go for a "scattered" setup: 
    
    a) GitHub for the repository (assuming you like Git)
    
    b) (Optional) LightHouse for bug tracking
    
    c) RubyForge just for the gem
    
    I'd still like a *proper* directory of gems (with a proper search), maybe scraping RubyForge data (like APIdock did with Ruby/Rails/RSpec documentation). Did anybody ever come up with something similar? Would anyone be interested?
date: 2008-11-08 13:34:00 +01:00
tags: 
- ruby
- programming
type: article
toc: true
-----
Back when I wrote my "10 reasons to learn Ruby":/articles/10-reasons-to-learn-ruby article, I mentioned "RubyGems":http://www.rubygems.org/ in _Reason #1_ as one of they key features of the Ruby programming languages.
Indeed, gems make getting Ruby programs as easy as typing @gem install <something>@ from the command line. When you want to distribute something new in Ruby, there's no need to give people download links, zip files or setup programs, just "tell them to get the gem":http://adam.blog.heroku.com/past/2008/11/2/pony_the_express_way_to_send_email_from_ruby/. That's perfectly normal, and extremely cool.

Gems are normally stored on "RubyForge":http://rubyforge.org, so all you have to do is uploading your gem there, and it will be available to the rest of the universe. It's a nice feeling. I remember when I first uploaded "RawLine":http://rubyforge.org/projects/rawline/ and then tried @gem install rawline@ just for the hell of it: it downloaded and installed the gem, as expected.

Back in the day, if you wanted to find something written in Ruby, all you had to do is search through RubyForge, and you'd eventually find it, with a bit of luck.


h3. Can we just have git, please?

RubyForge had, until recently, one major problem: it only allowed CVS and SVN repositories, and you had to make your choice when creating the project, once and for all. So when the cool guys at "GitHub":http://github.com/ rolled out their _social code hosting_ web site, most of the _créme de la créme_ of RubyForge flocked there in mass migration: "Rails":http://github.com/rails/rails/tree/master, "Merb":http://github.com/wycats/merb-core/tree/master, "RSpec":http://github.com/dchelimsky/rspec/tree/master... you name it.
Once the big guys made the switch, a lot jumped on the GitHub bandwagon of course. Result: we have a lot of projects still on RubyForge, but quite a few (and important ones) on GitHub. 

Why did people move there? Well, at first it was because they wanted a sleek-looking git host, and RubyForge didn't offer git at the time. But "git is now available on RubyForge":http://drnicwilliams.com/2008/04/08/git-for-rubyforge-accounts/, so why don't people use it? 
I'd like to know how many people use git on RubyForge. Apparently you can have your old SVN repository manually migrated to git, if you ask nicely (and RubyForge people are very helpful always, anyway). Still, I don't think many people use git there, and hardly anyone (if any) moved back from GitHub.

What's so special about this new "social code hosting" site then? I guess just a few key features:

* Fast and reliable git hosting
* The ability to "watch" other people's repositories and interact with them "the git way", also by forking.
* There's a whole new and fresh community feeling to it: you can follow people, message them, etc.
* The interface is much more neat than RubyForge's (OK, granted, it doesn't take much)
* Really cool stats and graphs
* A basic, but functional, wiki

h3. ...oh, and bug tracking, too!

GitHub has no bug tracking features. It tracks an awful lot of stuff about your repositories and people working on them, but "batteries are sold separately". You can get batteries "here":http://lighthouseapp.com/, for example. Apparently, GitHub and LightHouse are seamlessly "integrated":http://github.com/blog/41-service-integration.

So now you can sign up to two cool brand new web applications with neat interfaces instead of sticking with the old-looking RubyForge (which comes with "batteries included", after all). 
Personally *I'm very confused now*. Fortunately I don't have any extremely cool projects used by thousands of people, so jumping from one source code hosting solution from another is not really an issue for me, but I imagine it would be for others! Correct?

So, as far as I know, if you are a Rubyist, here's what you can do:

# Stick with RubyForge: it's not so bad after all.
# Embrace GitHub (and Lighthouse): it's extremely nice to use. Some people are not "too convinced":http://groovie.org/2008/05/06/most-bizarre-git-service-and-other-stupid-rails-powered-businesses that this is the best choice though.
# Go for something in between, like "Assembla":http://www.assembla.com/, which actually has an _impressive_ list of features and is powered by Rails too, so you'll feel at home. "Google Code":http://code.google.com/hosting/ used to be another common choice, but sadly they don't offer git yet.
# Do-it-yourself, maybe using something like "Gitorius":http://gitorious.org/ and some open source bug tracking/project management solution.

So... what choice did _you_ make or are you planning to make?

h3. Moving houses

There's one simple issue to consider when moving your code to a new place: what happens to your _old_ place. If have a relatively popular project, a lot of people may have bookmarked your project page on RubyForge, or the RubyForge subdomain which you may have used as the "home page" for your project (in truth, most of the ones who moved away still use it).

You may setup a redirection to the new home page or put a notice saying that the project moved somewhere else and point visitors to GitHub and LightHouse, or to another web site, if you wish. When "Rails moved to GitHub":http://weblog.rubyonrails.org/2008/4/11/rails-premieres-on-github, that wasn't much of a problem as Rails has its own web site.

What may become a problem is your old repository. In Rails' case, they left the old SVN repository available on sourceforge for a while and then removed it altogether. Other project owners have just abandoned their old repositories, occasionally resulting in "someone else":http://webby.rubyforge.org/ deciding to leave a note as their "last SVN commit":http://webby.rubyforge.org/svn/trunk/.

These solutions all work (you eventually drive people to the new home of your project), but it's not very nice, that's all. What happens if someone comes up with something cooler than GitHub? In all honesty, you may end up moving house over and over again.

h3. Don't forget the gems!

One thing I liked about RubyForge, as I wrote at the beginning, was that if you uploaded a gem there, it was immediately available to everyone typing @gem install <something>@.  
Luckily, "GitHub supports gems, too":http://gems.github.com/list.html! We're saved. The page they put up is "utterly awful":http://gems.github.com/, but it does the job: you can have your gems hosted on GitHub.  

Good! So surely I can get Rails now, right? Yup: @gem install rails@ will get the latest version of Rails for you, straight from GitHub. 

Actually, no. It doesn't seem to work that way: sure you can get the latest rails in that way, but it will actually be downloaded from _RubyForge_ (go check the "downloads":http://rubyforge.org/frs/?group_id=307&release_id=27493, you'll see it there). 
So even if technically you got Rails, you got it from RubyForge. If you want to get gem from GitHub, you have to add it as gem source first (that's an _una tantum_ operation, luckily): @gem sources -a http://gems.github.com@.

So, yes, you can move to GitHub and you'll also get gem support: but please _remind the users_ that they have to add GitHub as gem source. Or, better, you should always remember to upload your latest gems to GitHub _and to RubyForge as well_.

h3. The present

To sum up:

* If you want, you can stay on RubyForge. It has git, it has gems, it's probably not nearly as prettier than competitors and is not as social, but it works.
* You can opt for GitHub+LightHouse, have a slick interface, plenty of features and your project will be scattered in 2 different places + your home page, and you'll also have to keep uploading your gems to RubyForge.
* At this point, you may even go for something completely different, like Assembla or your own setup, but still upload your gems to RubyForge.

The obvious solutions at this point would be that the folks who craft rubygems (the gem which makes the gems, to be clear) add GitHub as default source. Sure as hell when that happens other people will want that too (hey, I'll have gems.h3rald.com setup by then!). Is this the future? I hope not.

h3. The future?

You know there's a domain called "www.rubygems.org":http://www.rubygems.org/? It's where the gem _manuals_ are! 
As much as I love documentation, there's nothing wrong in moving all those documents and books to something like _docs.rubygems.org_, right? 
Then they could make RubyGems.org the _only_ official gem server and tell people they should upload their gems there if they want to distribute them efficiently (after manual approval, if necessary, like there is on RubyForge).

In this way:

* You wouldn't have to upload stuff to RubyForge anymore
* You could have the clever folks at GitHub to create a simple script to automate the upload
* You'd have virtually _all_ the gems in one place
* You'd put a good domain name (currently almost forgotten) to good use

While they are at it, *the clever folks at RubyGems.org could also setup a _proper_ gem directory with a _proper_ search*. I'm sure there would be plenty of people who could help, too!

It's not impossible, right? They said that making Rails/Ruby/RSpec documentation more accurate and accessible was impossible, but now there's "APIdock":http://apidock.com/, correct?

Personally I'd like it to be a collaborative effort of the Ruby community (like ruby-lang.org), rather than one private company showing off, but I think everyone will be happy as long as it works.
I'm sure people will contribute, I would try at least (after finishing the Italian translation of ruby-lang.org, that is... erhm, well, that's another story...).

Thoughts?