Ever used a rubygem, found a bug, and just wanted to quickly bust out the big guns and fix it quickly?

The gem command doesn’t come packed with a way to find the original source repository for a gem. At best, most gems at least come bundled with the complete source, tests and documentation. Some gems don’t. Fair enough, since having access to the complete source via the gem still doesn’t allow you to fix a bug and share it with the world.

For that you access to the repo, a quick way to fork it, and a post-github way to share a gem version from yours truly.

The github gem and gemcutter are the modern day tools of master hackermanship.

Instant forking fun

Let’s say you find a bug in a gem, say rails, and you want to go to town on its source.

You know the gem is called rails but you’ve no idea what the github repo is called. Never fear.

@Luis + Aaron, I deep down agree with you. Ultimately github’s mechanism encouraged the path of username-prefix forking of gems for the last year or so.

I don’t believe rubyforge stopped anyone from pushing out a “drnic-rails” gem – you just need a project of any name and you can push dozens of gems through it (the seattlerb project hosts all their gems, instead of one project per gem).

Gemcutter makes it even easier.

But both allowed someone to push out a “drnic-rails” without the permission of “drnic” nor “rails” maintainers.

@drnic But is the canonical gem source really the place to publish forks? Why not run a gem server instead? Or if you don’t want to do that, wait for the subdomain support from gemcutter.

Pushing forks to the canonical source seems like a Big DealÂ®, and not the best thing for having people try out some cool new feature you added to xyz gem. IMO if you’re pushing a fork to a canonical server you are saying “I want to replace you”.

I feel like the argument against what gemcutter’s doing is pretty similar to the argument against git. Why would you want people to be able to easily fork a project, if you let them do that then how is anyone ever going to know where the real true source lives?

Lots of logic to that, but people are smarter than that. 50 blah-rails gems out there on gemcutter? I bet they’re all scratching some itch, and I bet it’d serve the rails guys to take a look and see what’s going on to get an idea of what people are thinking. Also, as a user if I see 50 people forked that, I’m going to know that there’s some value in the whole X-rails gems, since that many people have found it useful enough to customize.

And towards the canonical’ness, if I make a gem and somebody forks it, and then a bunch of other people use the fork, and google ranks theirs higher, and gemcutter shows theirs has more downloads, why is mine better than that one? Let the best gem win.

The reason I’m totally sold on this is I’ve been reaping the benefits of this recently. Example:

1. my team finds a bug in the thinking-sphinx gem
2. we do what nic’s talking about and fork the source on github, fix it, push it, and send the primary maintainer a pull request (which is a big step I think a lot of people skip)
3. we want to use that code now, so using jewler + gemcutter we create a new gem named moneypools-thinking-sphinx out on the interweb with our fix (hadn’t seen nic’s helpers before)
4. on all our boxes (including production) we can just install the new gem using our normal gem tools (gem, rake gems:install, bundler) right away — no jumping through hoops.

That’s a really awesome experience, and incredibly convenient.

The final follow-up is the maintainer pulls in our changes and pushes a new version of his gem out there. Ours is now outdated. This is the tricky part where I’m not sure what should happen. Deleting it means anyone using it would be SOL, keeping it out there though might not provide much value. Gemcutter takes the ‘leave it there’ approach.

So my overall summary is I think this’s one of those cases where the hypothetical bad-cases are outweighed by the real-world convenience and experiences.

Sorry for the long-commont/post-hijacking/rant(?)

P.S. I do think the more features github/gemcutter/others add to help ferret out what are the most active/popular versions the better.

@Luis great points. I’m going to have to think about that some more. One thing that comes to mind though is that’s not a problem unique to namespaced gems, the same problem can occur with gem A depending on gem C version 1.0 and gem B depending on gem C version 1.5. I do readily admit that upgrading from gem A 1.0 to gem A 1.5 is probably much more likely to work than from moneypools-A 1.0 to gem A-1.0.

The other thing is a library’s probably requiring a non-default version of a gem for a reason. If they weren’t using a non-default version they’d probably do something like monkey-patching or something else under-the-covers to patch in the functionality they need. I’d much rather be debugging gem dependency issues than trying to debug a chain of patches applied to a gem.

But again, I do think most of the time people are going to go with a gem that is (one of or multiple of):
1. canonical
2. with a special feature they require
3. popular

1 should be the default (and will be with a good maintainer)
2 isn’t avoidable, if you need the feature and it’s not getting pulled in, what’cha gonna do
3′s not a good one to use unless ‘popular’ means maintained and the real one isn’t

WRT #2: Maybe the maintainer hasn’t pulled in “cool new feature x” for some *very important* reason. Or maybe the maintainer doesn’t know that there is demand. Is it the canonical author’s responsibility to keep an eye on all of the forks? Why not talk to the author about “cool new feature x” rather than publish a fork? If your fork is experimental, why are you littering the canonical gem repository with it?

WRT #3: In that case you need to take over maintenance of the canonical gem or change your gem name from “user-xx” to something else and make it a real replacement with different top-level .rb files. Then people can use the non-forked version without entering “what gem did I require this from” hell.

[...] wanted to quickly bust out the big guns and fix it quickly? Surely, we all have.. so he's written Hacking someone's gem with github and gemcutter to show us how to easily fork an existing gem, make our changes, and get it deployed on Gemcutter [...]