[Rubygems-developers] Specifying equivalent modules?
Charles Oliver Nutter
charles.nutter at sun.com
Tue Apr 17 23:52:02 EDT 2007
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"
- 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?
More information about the Rubygems-developers