Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Different flavors of a gem for different versions of Ruby

Reply
Thread Tools

Different flavors of a gem for different versions of Ruby

 
 
Ken Bloom
Guest
Posts: n/a
 
      11-02-2008
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/
 
Reply With Quote
 
 
 
 
David Palm
Guest
Posts: n/a
 
      11-02-2008
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.


 
Reply With Quote
 
 
 
 
Ken Bloom
Guest
Posts: n/a
 
      11-04-2008
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/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Gem versions and Gem lists different after update Älphä Blüë Ruby 1 07-22-2009 07:43 PM
RubyGems 0.9.1 calling a gem with gem '<gem>' Austin 7873 Ruby 5 01-27-2007 10:05 PM
Making new Flavors : Making a custom transferhandler for and drop applications ebby83@gmail.com Java 5 01-12-2005 11:10 AM
Detecting Unix flavors Andrew Thompson Java 21 09-08-2004 02:07 AM
OT: CSV flavors Jeff Thies HTML 2 07-22-2004 02:26 AM



Advertisments