Different flavors of a gem for different versions of Ruby

Discussion in 'Ruby' started by Ken Bloom, Nov 2, 2008.

  1. Ken Bloom

    Ken Bloom Guest

    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.

    --
    Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
    Department of Computer Science. Illinois Institute of Technology.
    http://www.iit.edu/~kbloom1/
    Ken Bloom, Nov 2, 2008
    #1
    1. Advertising

  2. Ken Bloom

    David Palm Guest

    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, 2 Nov 2008 14:38:53 +0900, Ken Bloom wrote:
    > 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.
    David Palm, Nov 2, 2008
    #2
    1. Advertising

  3. Ken Bloom

    Ken Bloom Guest

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

    > 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, 2 Nov 2008 14:38:53 +0900, Ken Bloom wrote:
    >> 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.


    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

    --
    Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
    Department of Computer Science. Illinois Institute of Technology.
    http://www.iit.edu/~kbloom1/
    Ken Bloom, Nov 4, 2008
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrew Thompson

    Detecting Unix flavors

    Andrew Thompson, Sep 5, 2004, in forum: Java
    Replies:
    21
    Views:
    1,705
  2. Replies:
    5
    Views:
    1,864
    Andrew Thompson
    Jan 12, 2005
  3. Jeff Thies

    OT: CSV flavors

    Jeff Thies, Jul 21, 2004, in forum: HTML
    Replies:
    2
    Views:
    420
    Jeff Thies
    Jul 22, 2004
  4. Austin 7873
    Replies:
    5
    Views:
    182
    Eric Hodel
    Jan 27, 2007
  5. Älphä Blüë

    Gem versions and Gem lists different after update

    Älphä Blüë, Jul 22, 2009, in forum: Ruby
    Replies:
    1
    Views:
    124
    Älphä Blüë
    Jul 22, 2009
Loading...

Share This Page