[Rubygems-developers] Specifying equivalent modules?
public at bagotricks.com
Wed Apr 18 00:15:55 EDT 2007
If you install multiple versions of the same gem for different platforms
in the same repo, you get that menu automatically. So it's safe, but it
complicates life for the majority of Ruby users. It doesn't just pick up
the right version automatically. Users have to manually choose every time.
So maybe JRuby should get its own additional default repo that it checks
before going to RubyForge? And only JRuby versions would be installed
there? I'm not sure if that's the best solution (or if it would even
work since I haven't tested it), but it seems a possibility.
But as Tim Hunter pointed out for RMagick, there's some value in people
knowing that they don't have the real thing if feature parity isn't
there (or big bugs are). So I'll follow his recommendation for now (even
if there's no official trademark on RMagick - which you could argue
infringes on ImageMagick anyway) with respect to my clone.
Charles Oliver Nutter wrote:
> 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
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
More information about the Rubygems-developers