[Ironruby-core] IronRuby version of existing gems
jdeville at microsoft.com
Tue Mar 2 13:07:45 EST 2010
I believe JRuby is doing the 1st one, which makes sense in my opinion. If possible we should prefer platform == “ironruby”, (or .net, do we need to differentiate .net and mono?), but accept others.
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be for porting existing gems to IronRuby? There could be two possible approaches:
1. Create a gem with the same name (“win32console” in this case), and specify platform==”ironruby”. That way, dependent gems do not need to be updated, and users have to remember just one name. IronRuby will use the version with platform==”ironruby”, and MRI will use the one with platform==”mswin32”. So there should not be any clashes even if you use MRI and IronRuby on the same machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in general?
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem install locally first.
Please let me know if you still have trouble installing it from Rubygems.org.
Also, I've submitted a patch to RSpec to use iron-term-ansicolor if it can, the same way it tries to use win32console under MRI.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ironruby-core