RubyGems woes

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.

Does anyone have a better solution for this?

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

?

Maybe they’ll come in handy.

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.

Does anyone have a better solution for this?

The last section of
http://wiki.github.com/rogerdpack/ruby_code_tutorials/gem
might be helpful.
-r

On Mon, Sep 28, 2009 at 1:25 PM, Roger P. [email protected]
wrote:

The last section of
http://wiki.github.com/rogerdpack/ruby_code_tutorials/gem
might be helpful.

Looking at this:

http://github.com/mark-moseley/ruby-debug-ide/blob/master/ext/mkrf_conf.rb

I’m a bit confused… does this replace the normal RubyGems dependency
mechanism? (i.e. dependencies specified in the GemSpec)

On Tue, Sep 29, 2009 at 4:46 AM, Roger P. [email protected]
wrote:

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 :frowning:

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.

  • Charlie

Looking at this:

http://github.com/mark-moseley/ruby-debug-ide/blob/master/ext/mkrf_conf.rb

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.

HTH.
-r

On Oct 7, 7:14 am, Charles Oliver N. [email protected] wrote:

to get worse as we have more Ruby impls coming online.

This brings again the issue that RubyGems has not been prepared to
deal with multiple implementations.

http://blog.phusion.nl/2009/02/02/getting-ready-for-ruby-191/

Or multiple versions either:

http://rubyforge.org/pipermail/rubygems-developers/2009-April/004522.html

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.

On Mon, Sep 28, 2009 at 2:49 PM, Tony A. [email protected] wrote:

gems that aren’t needed on JRuby. Â This seems like a bit of a hack.

Does anyone have a better solution for this?

Have you looked at rip? http://hellorip.com/about.html

Maybe you could package jruby-deps.rip and mri-deps.rip or something
similar…just a thought.

Best,
Michael G.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs