RubyGems woes

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

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?

 

[Aldric Giacomoni]

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.

 

[Roger Pack]

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

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

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)

 

[Roger Pack]

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

 

[Charles Oliver Nutter]

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. =C2=A0correct me if I'm w= rong
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

 

[Luis Lavena]

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.

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.

 

[Michael Guterl]

We're trying to support both MRI and JRuby for a project, and have a numb= er
of "internal" gems our software is packaged into.

What would be *great* is a means to have variadic gem dependencies, selec= ted
based on the current RUBY_ENGINE. =C2=A0Many of the gems we need on MRI a= re
irrelevant on JRuby or require JRuby-specific alternatives.

Since I don't have this, I've ended up making two gem servers, one for MR= I
and one for JRuby. =C2=A0I've ended up loading the JRuby server with some= "dummy"
gems which don't actually do anything but fulfill the gem dependencies fo= r
gems that aren't needed on JRuby. =C2=A0This 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 Guterl