We’re trying to support both MRI and JRuby for a project, and have a
number
of “internal” gems our software is packaged into.
What would be great is a means to have variadic gem dependencies,
selected
based on the current RUBY_ENGINE. Many of the gems we need on MRI are
irrelevant on JRuby or require JRuby-specific alternatives.
Since I don’t have this, I’ve ended up making two gem servers, one for
MRI
and one for JRuby. I’ve ended up loading the JRuby server with some
“dummy”
gems which don’t actually do anything but fulfill the gem dependencies
for
gems that aren’t needed on JRuby. This seems like a bit of a hack.
I don’t know what the output for these would be, but are you familiar
with the following environment variables:
RUBY_DESCRIPTION RUBY_PLATFORM RUBY_VERSION
I’ve ended up loading the JRuby server with some
“dummy”
gems which don’t actually do anything but fulfill the gem dependencies
for
gems that aren’t needed on JRuby. This seems like a bit of a hack.
You could create an executable called
install_gem_xxx_platform_dependencies
then users have to do
$ gem install gem1
$ install_gem_gem1_platform_dependencies # installs more gems for you
Sorry, but this strikes me as pretty gross
You might be able to create different version of the same gem, that
target different platforms, like
gem1-mswin32-60 and gem1-jruby-60
and have different dependencies listed in each. Â correct me if I’m wrong
but I think this still would not allow for gem1-mswin32-60 to install
different gems based on the ruby version [i.e. different for 1.8 and
1.9].
This and the other workarounds also seem pretty gross…I feel like
RubyGems should be doing this for you. And the problem is just going
to get worse as we have more Ruby impls coming online.
I’m a bit confused… does this replace the normal RubyGems dependency
mechanism? (i.e. dependencies specified in the GemSpec)
Let’s see…no.
The itch that needs scratching is gem dependencies that differ per
platform and per ruby version.
In theory there’s a few ways to get those “platform specific gems”
installed.
You could create an executable called
install_gem_xxx_platform_dependencies
then users have to do
$ gem install gem1
$ install_gem_gem1_platform_dependencies # installs more gems for you
You might be able to create different version of the same gem, that
target different platforms, like
gem1-mswin32-60 and gem1-jruby-60
and have different dependencies listed in each. correct me if I’m wrong
but I think this still would not allow for gem1-mswin32-60 to install
different gems based on the ruby version [i.e. different for 1.8 and
1.9].
You maybe could leverage the new hooks that gems provides.
Or you could “hack” the extconf.rb to install system dependent gems.
This is the equivalent of putting the
“install_gem_gem1_platform_dependencies” functionality into extconf.rb
itself, thus there aren’t two steps for a user to run to install a gem.
You can’t even tell RubyGems that “support 1.8 greater than 1.8.5 and
1.9 too”
Fix those issues seems important, and even more when developers try to
create tools or libraries that works seamlessly across versions AND
implementations of Ruby.
A recommended approach is wrap requirements into rescue blocks and
nice warnings, provide install message when the gem get installed and
also as the gem requirements text.
