[ruby-core:40276] Fwd: Re: Can rubygems save us from "binary-compatibility hell"?

< ^ > P N |<>|^_>< --- | ~ ...Help
Forwarding this again to ruby-core as received a postmaster delivery failure.

---------- Forwarded message ----------
From: Luis Lavena <luislavena / gmail.com>
Date: Sat, Oct 22, 2011 at 11:08 AM
Subject: Re: [ruby-core:40273] Re: Can rubygems save us from
"binary-compatibility hell"?
To: ruby-core / ruby-lang.org, "RubyGems Developers (ML)"
<rubygems-developers / rubyforge.org>


Hello,

Please see comments inline...

On Sat, Oct 22, 2011 at 5:21 AM, Eric Hodel <drbrain / segment7.net> wrote:
>
>> The other is a binary gem that includes a compiled extension
>> library.  阬齬挃 蠈懤摷玃擤 瞂 儌鍷 摵瀦氀殣╝摥 阬鴇>> is not a technical issue, but do you think it is reasonable
>> to make gem developers release their binary gems when new
>> Ruby is released?
>
> I think it depends on the developer.  阬 蝁罅錼 擩黀 檴 蠈蜲隮 謽敳緮襡 谾薃 鵿 灚 蝁蜧閷纍鐓斠鐓濿颾  阬濊鐓撦僸鏻瀁 檴 鐓櫻欈斀謥呯緮郪鍱濷觶禊澞鏵 濊 罅闀瞂 摷 睾蜧鍏殣闀摷 濊 魨瞂槴 濎 鐓謯黀 阬纈蝁蜧臇槴瞂鐀殣 鳺蠈>

Well, that depends on what are the dependencies of those gems. If the
gem just use C extension for speed and don't depend on external
libraries (e.g. RedCloth, rdiscount, hpricot) then is not an issue if
there is no binary gem for the newer version of Ruby.

But, this is a problem for more complex gems like EventMachine,
nokogiri and others that depend on externals (openssl, libxml2).

More than that, there is an existing problem with RubyGems that forced
us to create "fat-binary" gems which include binaries for 1.8.x and
1.9.x so gem can be installed properly.

Projects like rake-compiler made this task a bit more easy, yet still
requires gem author certain environment adjustments.

While 1.8.x usage has been reduced lately, it is still present.

With this ABI compatibility change it will require those gem authors
wanting to provide fat-binary gems for every single ABI version in the
same gem.

I've presented this issue before at rubygems developer list, April 2009:

http://rubyforge.org/pipermail/rubygems-developers/2009-April/004522.html

>> And, is it possible to allow users to use, with a new Ruby, an old gem that does not support the new Ruby with a warning?
>
> This would require further adjustments to RubyGems, but I think it is possible.  阬瀍檴 鐓撦艕黀翴隮摥蠈憼醲鐐 鐓黀僶殪 谾薃 貗瀔瀀摐 具瀍濎鵿瀁帑
>

Perhaps RubyGems' Specification will require to be extended to a list
of versions the gem is compatible with and not just one unique
version?

Those are my only concerns: gem authors overhead when packaging binary
gems and making more easy to gem users install them without falling
into the compile-your-own rabbit hole.

Thank you.
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup鵛y