Don't forget about RubyForge

July 22, 2008
Don't forget about RubyForge
Posted by judofyr at 15:49 - 23 comments
“”This is ABSOLUTELY true...github.com stands to cause more harm than good, if folks choose to operate in this way. Someone needs to solve this. If github makes deployers lazy...perhaps there's a way to solve it in code?jbwiv - July 22, 2008 16:11
“”I agree.PeterCooper - July 22, 2008 16:23
“”(Although I love Github as well ;-))PeterCooper - July 22, 2008 16:23
“”I was fretting about this the other day! I have added github to my gem sources permanently, but that doesn't solve the problem for users who don't know anything about github, doesn't solve the problem of having to know the username of the person who created the library, and doesn't solve the dependency problem. I agree with the above comment that github can stand to cause more harm than good. We need to have a central location for gems, or we need to get github and rubyforge into some sort of closer integration, or we're going to have a mess on our hands really soon.Brian - July 22, 2008 16:36
“”It would be cool if there was a way to authenticate / authorize a certain fork as being the "official" one, so that

gem install libraryname would install the official version of "libraryname" whether it's on Github, Rubyforge, or wherever. If "libraryname" exists on Github AND Rubyforge, then gem should ask for clarification (as it does with architectures).PeterCooper - July 22, 2008 16:42
“”I would make the argument that it's time to completely forget about RubyForge.

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.


Centralization is great, but I still have to wait a day or two before I get permission for a RubyForge project. I'm usually working on small bits of open-source (particularly gemified Rails plugins) that, in all honesty, aren't really worth the hassle of setting up a RubyForge project.

GitHub's gem server is completely democratized and automatic. This alone better fosters an open-source community and the rapid evolution of gems. I would say in the few short months it has existed GitHub has captured the vast majority of Ruby open-source repository hosting. It has supplanted RubyForge as the place where the code lives, why shouldn't it supplant RubyForge as the place where the gems live?

It may take "just a few minutes" to make a RubyForge release (not counting the initial time it takes to set up the project) but why make have extra hoops to jump through in the first place? I say adding GitHub to the default gem repositories in RubyGems would solve this problem in a better way than continuing to require the simultaneous maintenance of two systems, one of which is vastly superior to the other.

I don't mean to disparage RubyForge; its existence served as the gateway for dozens of open-source projects I use every day; however, GitHub has clearly won the hearts and minds of the Ruby community as the new, better way to do this. Remembering a few extra characters at the beginning of a gem's name is a price I'm readily willing to pay.

Also, gem query --remote | grep gemname. :-)mbleigh - July 22, 2008 16:44
“”GitHub gems didn't make me lazy, I was lazy before this. That is why I never published gems to RubyForge. GitHub just lowered the bar to entry so lazy guys like me can easily publish gems. I'm sorry, but asking me to not be lazy isn't going to work. :)

The problem is I don't know a thing about publishing gems on RubyForge, and whenever I attempt to learn I run away screaming. If there was a clean, simple, well documented way to get a gem from GitHub to Rubyforge, would I do it? Possibly.

I see GitHub fitting very well in the big picture. It's the place to birth new gems and see if there's demand for it. It's so convenient that putting a gem up takes little hassle and is perfect for development. Once it becomes more polished and popular, that is the time to move it to RubyForge.

As for the currently popular gems, yes, please stay on RubyForge.Ryan Bates - July 22, 2008 16:55
“”Ryan, you have a great point there. GitHub works great as a testing ground (and for lazy folks), but RubyForge does have an air of authority that would be a shame to completely replace.

I think we need a gem to publish GitHub-formatted gem projects to RubyForge! Now where do we host it...GitHub or RubyForge? ;-)mbleigh - July 22, 2008 17:17
“”First of all, RubyGems must never, never, never, NEVER lock itself to a SCM. Publishing a gem shouldn't require to learn Git.

But yes, RubyForge is old and there must be a better way of doing this. GitHub is clearly a step to the right direction.

--

You need no gem to publish GitHub-gems to RubyForge, just some instructions (it's not hard). What if I write a simple "howto upload a gem to RubyForge" and also include how to do it from GitHub?judofyr - July 22, 2008 17:33
“”I want to bring up one more point. The fact that GitHub prefixes the gem name with the user name says a lot to me. It's designed to hold a mass number of gems and have no problems like name collisions. But this comes at a cost: an ugly name.

To use a phrase from DHH, consider this syntactic vinegar. It's saying that this gem is like a garage sale. Anyone can do it and it's a bit dirty. If you want the official, clean, polished gem use RubyForge. That looks more like a store front.

To me there's a nice distinction between the two. Use GitHub for v0.x releases for development and to see the demand. On v1.0 add it to RubyForge to make it official once you know people want it.Ryan Bates - July 22, 2008 17:39
“”Thanks for the feedback.

All of the problems you present with folks hosting gems on GitHub are solvable I believe.

Some ideas we've already tossed around regarding your concerns:

- We create a 'Gem' event on GitHub when someone builds a gem, so if you're following that repo or that user, you'll know when they release something new

- Convince Eric Hodel to add gems.github.com to the default sources gem

- Allow for gem uploads, so they don't necessarily have to be built via the gemspec


The dependencies bug I believe is already fixed, because RubyGems 1.2 allows you to add multiple sources without it completely blowing up these days.

If you run:


$ gem sources -a http://gems.github.com


a lot of the unpleasant things are fixed.

I think the point is, as Ryan has already stated, is that hosting gems on RubyForge can be a pain and we think we've figured out a simpler solution on GitHub, so lets figure out how to make GitHub better.
pjhyett - July 22, 2008 17:44
“”RubyForge is in need of a massive overhaul. GitHub has nearly everything it has plus more. And with required dependencies just name the source and full name of the gem.

This isn't hard, and is well worth it for how easy it is to look through source code and follow gems on GitHub.Eric Cranston - July 22, 2008 17:48
“”"GitHub has nearly everything it has plus more."

Really? Does github have ticketing, docs, forums, etc? No, I don't think so. GitHub solves a very small piece of what RubyForge does.

That said, those same features tend to be rarely used at RubyForge, which is a shame. And, those features tend to kinda suck at RubyForge, which is double shame._what - July 22, 2008 17:54
“”Woe to you, Oh Earth and Sea, for the devil sends the beast with wrath, because he knows the time is short...
Let him who hath understanding reckon the number of the beast for it is a human number, its number is Six hundred and sixty-six
beelzebub - July 22, 2008 18:10
“”So, in summary:
- It should be easier to create a project on RubyForge
- It should be easier to release a gem on RubyForge
- releasing a gem should not tie you to a particular SCM
- github is awesome

So:
- +1 for RubyForge improving the create project/release gem process
- +1 for github adding "create rubyforge project" and "release as gem on rubyforge" features, so one could *easily* benefit from both.

As PJ pointed out, rubygems 1.2 solves some of the issues described in the article. For those familiar with linux package managers, you've had to deal with multiple "sources" before anyway, if you've ever wanted something nefarious like a DVD player which included some super-dangerous encryption that wasn't added to the primary distro source. "There must be only one!" does not quite sound ideal.

So with that:
+1 for gems.github.com being added as a default source to rubygems
brian doll - July 22, 2008 18:10
“”CPAN!hekki - July 22, 2008 18:24
“”Should we start auto-publishing gems on RubyForge? Could be done, I reckon...Tom Copeland - July 22, 2008 19:40
“”Am I missing something, or is everyone here assuming that GitHub is a Rails/Ruby specific site? Coupling GitHub to gems is like coupling Rubyforge to a specific SCM, no? Not to mention GitHub is a commercial product, and Rubyforge is free.
Mark A. Richman - July 22, 2008 20:15
“”Mark: GitHub is free for open-source projects, which is all we're talking about here. Yes, GitHub is not Ruby-specific, but it's certainly Ruby friendly (and built in Rails).

Tom/PJ: In my crazy fantasy world my open-source project lives on GitHub for its source, but there's a button on the project homepage that says "publish gem to RubyForge" and I click it and voila, my latest gem is on RubyForge. Would need someway to work out collisions and setup, but that would be the ultimate in gem publishing to me. I think if the GitHub guys and the RubyForge guys got together, they could come up with something magnificent!mbleigh - July 22, 2008 20:30
“”How about eggs.github.com so the Pythonic among us don't feel excluded ;)mrichman - July 22, 2008 20:58
“”The real problem seems to be that it's too hard to publish gems on RubyForge. Or that "nobody" knows how to do it. We need to make it easier to publish and easier to learn to publish.

It would be great if GitHub could have a "publish gem to RubyForge"-button, but I don't think they should do much more. I quote Ryan Bates:

Use GitHub for v0.x releases for development and to see the demand. On v1.0 add it to RubyForge to make it official once you know people want it.
judofyr - July 22, 2008 21:13
“”Good news! There already is a very simple way to publish gems to RubyForge.

Hoe was written by Ryan Davis of Seattle.rb to make publishing a one-line command (after some simple setup). Here's a tutorial I wrote:

Publishing RubyGems with Hoe.topfunky - July 22, 2008 22:28
“”Why is it hard to publish gems on RubyForge? Is it the gemspec file? Or is it the project creation and file upload part? Just want to make sure I understand what the problem is....Tom Copeland - July 25, 2008 19:30
“”

Post a Comment

Note: If you are a registered user, log in to populate these fields.

If you wish, you may use these HTML tags to format your comment:
<a href="" title=""> <b> <blockquote> <code> <em> <i> <strong>

FFLYERRAXX