Forum: Ruby Different flavors of a gem for different versions of Ruby

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
851acbab08553d1f7aa3eecad17f6aa9?d=identicon&s=25 Ken Bloom (Guest)
on 2008-11-02 06:40
(Received via mailing list)
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.
6bed507c0085d39447171b95c515a890?d=identicon&s=25 David Palm (Guest)
on 2008-11-02 13:39
(Received via mailing list)
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!)
851acbab08553d1f7aa3eecad17f6aa9?d=identicon&s=25 Ken Bloom (Guest)
on 2008-11-04 02:55
(Received via mailing list)
On Sun, 02 Nov 2008 07:37:17 -0500, David Palm wrote:

> On Sun, 2 Nov 2008 14:38:53 +0900, Ken Bloom 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 topic is locked and can not be replied to.