[Ironruby-core] IronRuby version of existing gems

Will Green will at hotgazpacho.org
Fri Mar 5 11:11:23 EST 2010


I'd have to talk to Luis Lavena, the current maintainer of win32console. I
might also have to make some code changes or test changes to make the .Net
specific stuff a no-op on the C version of Ruby (otherwise, it won't even
run). But I'd certainly be open to this. I'll drop him a line this weekend.

--
Will Green
http://hotgazpacho.org/


On Fri, Mar 5, 2010 at 10:45 AM, Shri Borde <Shri.Borde at microsoft.com>wrote:

>  We should push the change once the dust settles down. Let’s wait until
> the RTM to make sure that this all actually works as we would like it to.
>
>
>
> In the meantime, I would encourage all gem authors to play with this and
> see if there are any issues. “gem build” had the issue mentioned below. Not
> sure if jeweler etc will have any issues.
>
>
>
> Will, will you be renaming iron-term-ansicolor to win32console? Its your
> call whether you want to or not. However, if you do not, we should create a
> gem with platform=”universal-.net” and with the same name of a native gem,
> and see what the experience is (does “ir.exe –S gem install” prefer the .NET
> gem over the native gem?). I did verify that “ir.exe –S gem install
> win32console” currently does not find any matching gem since the existing
> win32console is a native gem.
>
>
>
> *From:* ironruby-core-bounces at rubyforge.org [mailto:
> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green
> *Sent:* Friday, March 05, 2010 7:08 AM
>
> *To:* ironruby-core at rubyforge.org
> *Subject:* Re: [Ironruby-core] IronRuby version of existing gems
>
>
>
> Cool beans!
>
>
>
> I noticed in the latest push that a change was made to Ruby Gems itself:
>
>
>
>
> http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0
>
>
>
> Someone should contribute that change to the Ruby Gems project as well.
>
>
> --
> Will Green
> http://hotgazpacho.org/
>
>  On Thu, Mar 4, 2010 at 7:36 PM, Shri Borde <Shri.Borde at microsoft.com>
> wrote:
>
> With my last checkin, RbConfig::CONFIG[“arch”] will be “universal-.net2.0”
> for IronRuby. I created a gemspec as shown below. Doing “gem build” on it
> will create a gem with filename of Shri-1.2.3-universal-unknown.gem.
> Instead use “rbx –S gem build” and you will get a file called
> Shri-1.2.3-universal-.net.gem.
>
>
>
> spec = Gem::Specification.new do |s|
>
>   s.name = 'Shri'
>
>   s.version = '1.2.3'
>
>   s.summary = "Shri summary"
>
>   s.platform = "universal-.net"
>
>   s.description = %{Shri description}
>
>   s.files = []
>
>   s.author = "Shri"
>
>   s.email = "shri at email"
>
>   s.homepage = "http://shri.org"
>
> end
>
>
>
> I have updated with
> http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems with
> this info:
>
> *IronRuby-specific gems *
>
> Gems could specifically target IronRuby. They may contain Ruby code which
> uses .NET APIs, or they may even include compiled .NET assemblies. In such
> cases, the Gem specification should set platform
> <http://rubygems.org/read/chapter/20#platform>to "*universal-.net*" (or "*
> universal-.net4.0*" to run only on .NET 4), and build the gem using
> IronRuby ("rbx -S gem build").
>
> Note that if you build the gem with MRI using "gem build", MRI will not be
> able to recognize the platform string, and will create a gem file named
> something like foo-universal-unknown.gem (instead of the expected
> foo-universal-.net.gem"). To avoid this, build the gem using IronRuby as
> mentioned above.
>
> Talking with Tomas, we will leave RUBY_PLATFORM set to “x86-mswin32” (on
> Windows) since many apps check for “mswin32” in RUBY_PLATFORM to check if
> they are running on Windows. We considered *appending* “.net” and setting
> RUBY_PLATFORM to “.net-mswin32” or “x86-mswin32/.net” to indicate that it
> was not MRI, but decided against it as you can always check RUBY_ENGINE to
> detect if you are running on IronRuby.
>
>
>
> *From:* ironruby-core-bounces at rubyforge.org [mailto:
> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green
> *Sent:* Tuesday, March 02, 2010 11:52 AM
>
>
> *To:* ironruby-core at rubyforge.org
>
> *Subject:* Re: [Ironruby-core] IronRuby version of existing gems
>
>
>
> That all depends on how Gem checks the platform.  If it uses the
> RUBY_PLATFORM variable, then IronRuby needs to change what it reports here.
> Currently, it reports i386-mswin32.
>
>
> --
> Will Green
> http://hotgazpacho.org/
>
> On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at microsoft.com>
> wrote:
>
> 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.
>
>  JD
>
>  *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
> *To:* ironruby-core
> *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.
>
>
> --
> Will Green
> http://hotgazpacho.org/
>
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100305/3315fcf6/attachment.html>


More information about the Ironruby-core mailing list