-aaalex

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.

@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

/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require’: no such file to load — highline (LoadError)

need to add highline as a dependency.

Thanks for this nice helper gem, i’m trying it out right now.

While your logic sounds reasonable, and under certain circumstances valid, it just turn into a complicated environment for new comers.

For example, in your case, let’s say your Rails/Merb applications depends on this moneypools-thinking-sphinx.

Because is a cool project, or someone want to put it in their system, they clone it and start dealing with the dependencies.

Either using Rails gem dependencies or Bundler, you would get moneypools-thinking-sphinx, which is cool.

That is because both Bundler and Rails-gem mechanism uses gem 'foo-bar' prior the require of the library.

Now, things turn hairy for people that do not pollute their scripts with gem statements.

As my example in the group, I found issues with some users that had installed relevance-rcov and others spiceycode-rcov, which both offer “rcov.rb” to the require method.

Of course, relevance was loaded first, but could be “abc-rcov”, with lower version number than relevance which could be loaded due this simple require.

So, now you want to help out someone that is doing require ‘rcov’ and you ask “please tell me the version of rcov gem you have installed”

gem list rcov will throw no results.

Instead, the need to do gem search rcov, which will also bring a lot of noise to the results.

Now try to explain to that user “ok, you got the wrong rcov” and the answer will be “I haven’t installed it, was installed by XYZ, but MN uses this other version”

All the above, is not hypothetical, I’m giving a simple example of something that already happened to me and some users contacting me about RubyInstaller.

So, after you burn with this stuff a couple of times… instead of catching it late, why not fix the root of the issue?

In my company we built our own gem server and published there even gems for our private projects, not just open-source forks, that worked for us, and could work for others.

Apologizes for the long answer and my english, which I believe sometimes is not good enough to explain myself.

Cheers.

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.