-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.