[Rubygems-developers] Specifying equivalent modules?

Charles Oliver Nutter charles.nutter at sun.com
Thu Apr 19 03:09:25 EDT 2007

Thomas Palmer wrote:
> On this topic, if you specify a gem platform, you get a gem named like so:
> <gem>-<version>-<platform>.gem
> And it can coexist in a remote (or even local repo) with platformless 
> versions or versions for other platforms. When installing, you get a 
> menu of choices. Probably could just drop in the "-java" version into 
> RubyForge's repo, but it risks social strain perhaps.

That social strain is exactly what I want to avoid. I think you're 
right, I could just publish a mongrel-#.#-java.gem file to RubyForge and 
it would work, but that seems like a good way to start pissing people off.

> And it has the other drawbacks I mentioned. And I bet you could get 
> complaints on the "please choose your gem" (or however that's worded) 
> menu for gems that previously didn't have the pain.

Though in most cases, the gems that would have a choice with Java added 
will already have a choice now (since they'll depend on native code...if 
they didn't, we wouldn't need a Java version). I don't think this is 
likely to be as big an issue, but obviously if RubyGems could just pick 
the right platform it would be a complete non-issue (i.e. if there's a 
choice of platform and "java" is one of them, that's guaranteed to be 
right for us...and wrong for anyone not on JRuby).

> Maybe that "provides" idea from darix could work. So install would be 
> different but local use would be fine. (Note that I'd still like to see 
> different local gems defaulting to be active for different local rubies, 
> even multiple installs of normal ruby.)

This is basically what I had in mind, but I've never tried to design or 
specify a package management system, so it's all pretty cloudy. Whatever 
works for other systems would probably be applicable here. All I know is 
that I want to be able to provide drop-in-replacement Java versions of 
C-based gems with as little strain on the original authors as possible.

- Charlie

More information about the Rubygems-developers mailing list