[Rubygems-developers] Specifying equivalent modules?
Charles Oliver Nutter
charles.nutter at sun.com
Wed Apr 18 01:01:01 EDT 2007
Jim Weirich wrote:
> On 4/17/07, Charles Oliver Nutter <charles.nutter at sun.com> 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?
> Would it work to just make platform dependent variants of the gems in
> question? Currently, RubyGems will make you manually choose the right
> platform (future versions will autoselect the correct platform for
I think it's more than just choosing the right platform...it's an issue
that if every gem out there depends on "mongrel" there's not a thing we
can do to force them to install and run with "jmongrel", even if the two
are nearly identical.
> Allowing a user to specify an "equivalent" gem is an interesting idea.
> I would not like to see it at gem definition time tho, I would rather
> have it happen at installation time. But what would constitute
> equivalent? Gems works pretty hard at keeping versions correct in
> dependencies. Would equivalent gems have to have synchronized
> versions, or would we specify that version 1.0 of JXxxx is equivalent
> to version 2.3 of RXxxx? That could get confusing quickly.
I agree it could get very confusing. Obviously the simplest answer is
that for a given module name, we should have a gem each for every
supported platform. But in reality that puts a lot of burden on the
owner of that name, especially when we're looking at more and more ports
to JRuby that the original C extension authors are unlikely to want to
maintain. Perhaps there's a way a gem publisher could specify "my gem Y
is equivalent to gem X" so that any apps depending on gem X could
successfully install with gem Y. I've no concerns about pushing that
management onto the port developers, since it removes the burden from
the original gem authors.
I'd hate to think we've got an unfixable problem where only the "in
crowd" of C-based gems will ever get to play the game, but with hard
name-based dependencies it's going to be more and more difficult for gem
ports to swap in seamlessly...even when the swap might be the only way
that gem will work on a given implementation.
More information about the Rubygems-developers