[Rubygems-developers] Specifying equivalent modules?

[Charles Oliver Nutter]

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

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.

- Charlie