Forum: IronRuby Recommendations for (IronRuby) gem packaging ?

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.
Thibaut B. (Guest)
on 2009-02-28 12:54
(Received via mailing list)
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
Daniele A. (Guest)
on 2009-02-28 13:41
(Received via mailing list)
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
http://github.com/nrk/ironruby-hpricot/ ... 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
Thibaut B. (Guest)
on 2009-02-28 14:59
(Received via mailing list)
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
Jimmy S. (Guest)
on 2009-03-16 01:18
(Received via mailing list)
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?
Thibaut B. (Guest)
on 2009-03-16 12:25
(Received via mailing list)
>
> 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 (
http://github.com/thbar/diacritics_fu/tree/master) 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
Daniele A. (Guest)
on 2009-03-16 23:26
(Received via mailing list)
2009/3/16 Thibaut Barrère <removed_email_address@domain.invalid>:

>> 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.".

See also "gem help platforms"

> For instance, I have developed gems that target the MRI. I'm thinking about
> adding native support for IronRuby. One example is diacritics_fu
> (http://github.com/thbar/diacritics_fu/tree/master) 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.

In this case I would simply opt for two separate gems: diacritics_fu
(pure ruby) and diacritics_fu-ironruby. I don't think that MRI guys
are actually interested in having .NET assemblies in their installed
gems :-)

--
Daniele A.
http://www.clorophilla.net/blog/
http://twitter.com/JoL1hAHN
This topic is locked and can not be replied to.