Recommendations for (IronRuby) gem packaging?

thbar · February 28, 2009, 11:54am

Hi,
I’m thinking about packaging some gems from github.

So I’m wondering if it already possible to package a gem so that:
1 - it is marked as compatible only with IronRuby ?
2 - it is marked as compatible also with IronRuby (as well as other
platforms) ?

What would be the platform indication ?

I’m also looking for any other useful information from people who tried
to
package an IronRuby gem.

cheers and thanks for any feedback,

– Thibaut

thbar · February 28, 2009, 12:41pm

Hi Thibaut,

AFAIK there is no way (yet) to enforce the compatibility of a gem with
one or more ruby implementations, e.g. mri, jruby, ironruby, etc. If
I’m not going wrong there was a discussion a while back on ruby-talk
about the necessity of extending the current gemspec with a new
attribute to meet this kind of requirement as the existing “platform”
attribute was not intended for something like this and, in fact, it is
not quite the same.

I was thinking of packaging my ironruby-hpricot as a gem for ironruby
(btw the source is hosted on github, see
GitHub - nrk/ironruby-hpricot: A port of Hpricot to IronRuby … never had the chance to
announce it :-)) but I guess it is too early as ironruby’s internals
seem to be still a “moving target” (I had to push a few fixes last
week due to changes).

On Sat, Feb 28, 2009 at 11:29, Thibaut BarrÃ¨re

thbar · February 28, 2009, 1:59pm

Hi Daniele,
nice to see your work on HPricot - I wasn’t aware of that. That will be
totally useful

thanks for your reply - I guess I’ll remain in pure code on github until
things are sorted out.

thanks!

– Thibaut

thbar · March 16, 2009, 12:18am

Isn’t “platform” used to identify a gem as a JRuby gem? Granted, it’s
not perfect, but having IronRuby gems set the platform to “ironruby”
would seem to make sense with the current state of rubygems. Is there a
reason not to do this, and (other than waiting for changes to rubygems)
is there a better way to accomplish this?

thbar · March 16, 2009, 11:25am

Isn’t “platform” used to identify a gem as a JRuby gem? Granted, it’s not
perfect, but having IronRuby gems set the platform to “ironruby” would seem
to make sense with the current state of rubygems. Is there a reason not to
do this, and (other than waiting for changes to rubygems) is there a better
way to accomplish this?

I think it is - although I’m no expert here.

As well, I’m not sure what setting the “platform” actually implies.

For instance, I have developed gems that target the MRI. I’m thinking
about
adding native support for IronRuby. One example is diacritics_fu (
GitHub - thbar/diacritics_fu: Tiny Ruby library to remove accents and other diacritics from a string (relies on ActiveSupport).) that removes accents
from
strings. Under .Net, I can achieve that natively using encoding stuff.
So
basically this gem would become usable under both MRI and IronRuby, it
just
doesn’t use the same underlying stuff depending on who is using it.

I anticipate that more and more gems could face this situation.

I’m not sure how to define the platform in these cases.

raw thoughts…

– Thibaut

thbar · March 16, 2009, 10:26pm

2009/3/16 Thibaut BarrÃ¨re [email protected]:

Isn’t “platform” used to identify a gem as a JRuby gem? Granted, it’s not
perfect, but having IronRuby gems set the platform to “ironruby” would seem
to make sense with the current state of rubygems. Is there a reason not to
do this, and (other than waiting for changes to rubygems) is there a better
way to accomplish this?

I think it is - although I’m no expert here.

Well it makes sense if we are speaking about a mere reminder that a
gem targets ironruby (it is not really that good, but there is no
other way to do that), but right now it is not possible to enforce
the compatibility with a specific ruby implementation and/or platform
(and this is what I was referring to).

By the way… yes, a few gems just use spec.platform to identify
themselves as jruby gems:

hpricot-0.6.164.gem
hpricot-0.6.164-mswin32.gem
hpricot-0.6.164-jruby.gem

Honestly, the fact that spec.platform was intended for different
purposes does not imply that we should not follow what seems the
de-facto way to overcome the current limits of gemspecs

As well, I’m not sure what setting the “platform” actually implies.

http://rubygems.org/read/chapter/20#platform

“If this attribute is set to a non-default value, it will be included
in the filename of the gem when it is built, e.g.
fxruby-1.2.0-win32.gem.”.