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 —
I agree.
PeterCooper —
(Although I love Github as well ;-))
PeterCooper —
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 —
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 —
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 —
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 —
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 —
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 —
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 —
“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 —
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 —
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 —
CPAN!
hekki —
Should we start auto-publishing gems on RubyForge? Could be done, I reckon…
Tom Copeland —
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 —
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 —
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 —
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:
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….
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?
I agree.
(Although I love Github as well ;-))
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.
It would be cool if there was a way to authenticate / authorize a certain fork as being the “official” one, so that
gem install librarynamewould 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).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, 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? ;-)
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?
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.
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.
“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.
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
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
CPAN!
Should we start auto-publishing gems on RubyForge? Could be done, I reckon…
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: 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!
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.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.
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….
Post a comment