[Rubygems-developers] Specifying equivalent modules?

[Charles Oliver Nutter]

Is there a way in RubyGems today to specify that one of a number of 
modules would be considered equivalent, and to load whichever is 
actually present? So that during install, options could be presented for 
multiple named gems that provide the same functionality?

The reason I ask is that more and more we're seeing gems with C 
components being ported to Java for use in JRuby. In general, these 
modules can be re-released under a new name (rmagickjr, jparsetree) and 
work just fine in isolation. However, since gem dependencies are 
specified by name, these ports frequently won't be useful when 
installing a group of modules.

Take Mongrel for example. There's a working port of the Ragel code for 
Mongrel that would allow a gem to be published for JRuby. But we don't 
like having to hassle Zed to publish code he doesn't own, and it doesn't 
seem like it should have to be his responsibility. But any gems that 
depend on Mongrel depend on Mongrel alone, and there's no way to have 
them load "JMongrel" instead. They'll either succeed to install Mongrel 
or they'll fail...and generally they fail since there's native code 
involved we can't run in JRuby.

So what's the answer to this problem? At the moment, there are at least 
four modules being used by JRubyists that have non-Ruby components:

- Hpricot, for which _why has published a JRuby gem on his local repository
- Mongrel, which is working and has all the pieces ready to go if we 
could get it published somewhere
- JParseTree, which is working, published, and up-to-date with current 
JRuby, but which can't be installed where dependencies on "parsetree" 
are specified
- RMagicJr, which has much of RMagick's functionality and has been 
published, but which again can't be installed where dependencies on 
"rmagick" are specified.

So it seems like we need some other option for specifying dependencies 
or specifying that one released module can substitute for another. Ideas?

- Charlie