Gem building has been disabled since the move to Rackspace. This was because the system had to be rewritten to work with the new architecture and we had to provision an entirely new VM for the sandboxed gem building – things we didn’t want holding up the move.
Well, it’s been a week and we’ve decided to not bring back the gem builder. It was a fun experiment but Jeweler and Gemcutter combined make it ridiculously simple to publish a gem. The gem builder use case (fork a project, make a change, publish a gem, install it) is now easier than ever using these tools.
As for namespace support, Gemcutter is working on it. We encourage you to help!
We will continue to serve old gems at http://gems.github.com/ for at least one year. Thanks.
More direction on where Gemcutter is going: http://groups.google.com/group/gemcutter/msg/01883786d8c2a512
I welcome our new gemcutter overlords.
Hell. Yes.
Yay centralization. Oh wait. No, no yay.
This is why everyone shouldn't have been so quick to migrate their gems from RubyForge to GitHub in the first place
@cpjolicoeur Better not ever buy a new computer - you know they'll just come out with an upgraded version in the future ;)
Thank, God.
What a nasty surprise. Well, lucky me: Just a tiny number of gems to migrate -- let's hope their names are still not in use...
Holy crap this sucks. I understand the reasoning on your side, and there is no contract anywhere that says you have to continue providing this service, but Holy. Crap. I'm thinking this really sucks for my little one-off Rails plugins that I gem-ified on GitHub cuz it was so stinking easy. Now I have to build the gems myself and host them elsewhere, as well as tell anyone who added a gem.config line to their environment.rb with links to my gems on github -- well those gotta change too.
Like I said, I understand your reasoning. Just sayin'.
Well, that sucks. I know that I and many others just loved this feature!!!
Just update your gem sources, install gemcutter, and push. No biggie folks.
well, no biggie if you don't mind updating all your old projects, readmes, etc. so that they match the new deal.
I liked GitHub's gem hosting because it was easy, not because of the required namespacing (I actually hated that). Gemcutter is canonical and easy to use, which is the best of both worlds.
I'm glad GitHub played a part in the transition to a better gem hosting system. Thanks guys.
Anyone who thinks building a gem is hard should really, really take a look at Jeweler. All you need to do is install jeweler then copy and paste 14 lines from their README into your Rakefile.
Boooo! Hissss!
Oh wait, we are rubyists, gotta find the new hotness way that everybody is supposed to use now.
;)
Any other features going away with the move?
@spicycode, yes, weekly file-system induced restarts.
Is there any possibility for a gemcutter post-hook? I really liked the ability to auto-push gems.
@swindsor That's an awesome idea! The post-hooks are open source, check them out: http://github.com/pjhyett/github-services
"The gem builder use case (fork a project, make a change, publish a gem, install it) is now easier than ever using these tools."
This isn't entirely true, at least on the Jeweler side. It only supports pushing to Gemcutter without a namespace currently. I've been working on support for this though, and hope to have it out soon.
@swindsor: Implementing the post-receive hook for repos would require building gems, since Gemcutter only accepted built gems. This was one of the main problems with GitHub's gem builder in the first place, but if somehow you can think of a way to avoid this I'm open to it.
@technicalpickles: awesome news - that's why I liked the github gem builder. I could fork a project, modify the smallest detail and have a gem I could install onto any host with a net connection.
I'm crying...
I like this move!
Y'know, a little bit of notice would have been nice, rather than having it disappear, and a week later come up with 'we can't be bothered to fix it'.
Just sayin.
Y'know, a little bit of notice would have been nice, rather than having it disappear, and a week later come up with 'we can't be bothered to fix it'.
Just sayin.
@lstoll What would the notice allowed you to do that you cannot do right now, other than build more gems? :)
Good move guys, the forced namespacing of github gems always concerned me.
While I can understand why you needed to disable this feature, I think the communication of this change has been subpar, especially for customers that are paying for your service which include(s|d) gem building.
Most of the gems that I publish scratch my own itches: I use them all in my production applications. I had put in a lot of effort to make sure that updated gems would get installed correctly. I also have to update the installation instructions for all the other gem users that also have to go trough these hoops. I did not want to do this work because I was under the impression that gem building would return at some point. Additionally, one of the gem versions that Github is serving was faulty (due to my own fault). I immediately fixed this, but I could not publish this bugfix release anymore. So all users of this gem will get errors when they update to the newest version available on Github. I can only hope that they will check the wiki to see the warning and migration instructions
Finally, because the exact future direction and fate of Gemcutter and Rubyforge are not yet figured out as far as I can see, I did not want to migrate everything when there is a chance that I have to go through all those hoops again.
So, I think the least you could have done was a notice prior to disabling the gem builder, so i would have been able to do my preparations for a smoother transition.
Really annoying. First all the stuff disappeared from rubyforge (well, at least the recent versions), and now we (users) have to change our setups again.
And I don't want to blame only you, the ruby ecosystem, as diverse it might be, there is often no real continuation.
Aaaawwn... :(
Darn and just after I checked the 'Ruby Gem' check box for the first time with much delight! This was a really cool feature and truly painless to host the Gems of your project.
Eh, that's a dick move. Thanks a bunch.
It'd have been nice if this were coordinated with the resolution of the namespacing issue. We're kind of in a weird spot now.
The real problem is for gems who have had github as their canonical source and whose latest version has a bug. Too bad there isn't a way to set up a redirect or something that requires no user discovery.
I think it's safe to say that most rails apps are configured to pull in dependencies from github. Also, not all apps/libs end up being maintained... what about when someone else picks up development and becomes the de-facto source?
This is seriously disappointing github.
@semanticart Open a ticket at http://support.github.com if you need a gem tweaked because of bugs or problems.
@defunkt, thanks! I'll do that when i get my bugs fixed :)
@defunkt
your analogy of not buying a new computer because of upgrades is lost on me.
my comment had nothing to do with the credibility or superiority of gemcutter as a gem building platform. i have no problem building and hosting gems on gemcutter or rubyforge.
my comment is related to a lot of popular projects that previously hosted their gems on rubyforge and then started hosting all new updates to those gems only on github. it caused plenty of confusion in the first place as all gem updates where now downloaded via their namespace. now, those same gems are going to have to be pulled down from a third gem hosting location.
my comment wasn't bashing github for stopping to build gems, it was directed at gem authors who moved their sole gem hosting to github from rubyforge in the first place.
%(
It's terrible...
Well, this sucks.
not optimal... I was enjoying getting gems to be served via github... that all in one place thing is cool. but I guess we will adapt.
On gem forking: http://litanyagainstfear.com/blog/2009/10/09/on-gem-forking/
Chiron Beta Prime http://www.youtube.com/watch?v=B3DyxaCYlfg
Working for our robot overlords, did I say overlords? I meant protectors.
Maybe I missed something, but the gem building seemed like a killer feature for github. I understand that sometimes a feature is just more trouble than it's worth, but I think this move will really end up biting you guys.
The original motivation for rip?
I feel it's dishonest, github profited from the marketing push of hosting gems and then suddenly stops that features leaving everyone hanging without so much as a heads up...
If you build such a system that everybody relies on (how many rails app use gems on as dependencies?), you should take responsibility for it and not just drop it without warning. How can people trust you later on?
Wow, what a shame.
Yeah I'm a bit disappointed about this as a paying customer ;( Github having the gems was really useful in my workflows.
I actually think this is a good move. GitHub was slow as molasses at regenerating gems anyway whereas Gemcutter gives me full control and works fast. I can build my own gem, push, and bam, it's ready for other people to get. Certainly beats getting out the prayer mat and hoping GitHub will regenerate the gem within a few hours.
This is one of those occasions where less is definitely more. If you're going to complain about it, I suspect you haven't really given Gemcutter a good try yet.
I've tried Gemcutter, and I like it, and I still think this is a shoddy move on Github's part.
It's not that changing to Gemcutter is hard, it's just that it really wasn't what I wanted to do right now. Having a workflow suddenly change and having to update references all over the place is an inconvenience, which is why the responsible thing would have been to give people time to plan for it. When all you want to do is to get out a bugfix, it's not the time to be fiddling around shaving yaks.
I'm a paying customer. The company I work for is a paying customer. I – we – rely on Github to get stuff done. Should I rely on a company that would drop a feature as precipitately as this?
Just wanted to publish my 1st gem.. no luck..
Have to go and discover gemcutter now..
Ummm get over it guys, It took me about 5 minutes per gem to get my stuff over onto gemcutter. Since when has the new great thing been scary? None of us know what's involved keeping github up and running, maybe we let them handle it, they do host open souce stuff for free after all ....
This makes me sad/frustrated – I really miss forking and the gem that appears in the upper right of repositories with them. There are so many branches of Pony for instance, it's nice to be able to grab just the one I want to fork.
Gemcutter has gems, yes, but not "social coding". Please bring back or replicate functionality.
More evidence that our decision to stop giving you boys money and roll our own git was the right one.
This is a major bummer. Saying it is easy just use Gemcutter is doesn't make sense. The problem is you now have to rely on others to publish their forks to Gemcutter. Isn't the special sauce of Github the ability to just fork and it is a first class gem ready to go? This is going to seriously marginalize forking, isn't it? Am I missing something here?
I dislike how now I can't browse a gem's code (unless gemcutter has this feature and hides it very, very well.) before grabbing it. The separation of code and release is a big bummer for me.
I agree that most of the whining is probably unnecessary. Just publish your gem on rubyforge or gemcutter. It's not that big a deal, but I still see a very real problem for forked gems (as opposed to original projects).
I guess a solution would be to just rename your gem and publish to gemcutter with the whole namespaced name. Hopefully a solution will be forthcoming about this, or perhaps the solution is not to fork gems, but send changes back to the original project.
That only leaves two(?) cases: 1) a gem that is no longer maintained, and 2) a change that would be (for some reason) unuseful to the forked project. I guess both these cases may warrant actually forking and renaming the project?
@bradly My thoughts exactly. Using a forked gems seems like it will be significantly more aggravating now. Right? Isn't this a big step backwards? Namespacing gems was a huge step forward in my opinion. No reliance on the original committer to not get hit by a bus etc. Now it's back to politics and getting on the approved gem releaser list. Blech. Please tell me I'm off the mark.
What about name collisions between gems with totally different codebases? oy vey.
-Incredulous that github has decided to throw us to the fishes without these issues even half way baked.
the gem building feature was great and the namespacing was totally in line with the project forking concept; clear separation between different projects origin, no confusion as to which is the 'original' gem. You choose supercoder-ultragem? heck, it's your choice, and you probably have good reasons for it. What is the difference between having multiple versions of the same gem, all clearly namespaced and having different forked versions of the same project?
I really miss the ability to fork a gem, commit my patch, automatically generate my gem version and have it available for use everywhere, right now.
@defunkt What would the notice allowed you to do that you cannot do right now, other than build more gems? :)
You can't be serious. Do you really think it's ok to completely disrupt people's workflow at a potentially critical time with no notice at all? I am a paying github user and this kind of attitude makes me wonder if I should stay. What am I going to lose next that I won't find out about until after it's gone?
DAMN! This sucks!
Yay!
I've never used autobuilding. However, the way this was done is seriously giving me a really bad impression of Github.
What's next? "Github is no longer accepting pushes to hosted repositories. Sorry, but it was taking up too much of our server resources, and it's so easy to switch to Gitorious now. We didn't bother telling you in advance because we figured there wouldn't be anything that you could do with that information other than pushing more code before the cutoff."
(OK, tongue in cheek, and it's not my ox being gored yet, but this was just unprofessional.)