Different flavors of a gem for different versions of Ruby

I’m updating my SqlStatement gem http://sqlstatement.rubyforge.org/ to
be
compatible with Ruby 1.9, and owing to totally different ways of doing
s-
expressions in Ruby 1.8 (which required RubyNode) and 1.9 (which can
trap
the not and != operators as methods, so I can use the interpreter itself
to generate everything I need in an s-expression), the Ruby 1.9 version
no longer requires a dependency on RubyNode. In fact, RubyNode doesn’t
exist for 1.9 AFAICT.

Is there a way to do one of the following in RubyGems?

  • create a Ruby 1.8 flavor of the gem and another Ruby 1.9 flavor.
    Preferably, I’d like the gems to have the same name and live side-by
    side on RubyForge.
    or
  • Have both versions of the dependencies exist in a single gem,
    but only enforce the RubyNode dependency when the gem is installed on
    Ruby 1.8.

Take a look at how the mongrel gem is doing it. It uses a bunch of
conditionals to distinguish actions to perform for jruby and mri. adding
in Ruby 1.9 support is (fairly) easy.

I forked mongrel the other day so I could take out the fasterthread
dependency (not needed for 1.8.6+); might be useful:
http://github.com/dvdplm/mongrel/tree/master

(and I’m sure it can be done more elegantly!)

On Sun, 02 Nov 2008 07:37:17 -0500, David P. wrote:

On Sun, 2 Nov 2008 14:38:53 +0900, Ken B. wrote:

Preferably, I’d like the gems to have the same name and live side-by
side on RubyForge.
or

  • Have both versions of the dependencies exist in a single gem,
    but only enforce the RubyNode dependency when the gem is installed
    on Ruby 1.8.

AFAICT from the metadata of the generated gems, this doesn’t do what I
want. It generates different gems on different versions of ruby, but
there’s no indication that these gems are different in the end. By the
way, I think you have a bug: if you generate the gem on Ruby 1.8.6, it
will be installable on Ruby 1.8.4 but won’t include the fastthread
dependency.

–Ken

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