Jim Weirich wrote: > On 4/17/07, Charles Oliver Nutter <[EMAIL PROTECTED]> 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 _______________________________________________ Rubygems-developers mailing list Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
