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

Luis Lavena luislavena at gmail.com
Sat Oct 22 05:08:40 EDT 2011


Please see comments inline...

On Sat, Oct 22, 2011 at 5:21 AM, Eric Hodel <drbrain at segment7.net> wrote:
>> The other is a binary gem that includes a compiled extension
>> library.  TEENY release will be done about every year.  This
>> 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.  I can make a list of recent platform gems so we can consult the authors.  With the addition of the Developer Kit for Windows rubyists it may not be as big a concern now as it has been in the past.  Luis can comment better here.

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:


>> 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.  Some of the adjustments are related to the stdlib gems proposal (coming soon).

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

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
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éry

More information about the RubyGems-Developers mailing list