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

On Thu, Nov 10, 2011 at 4:38 PM, Yusuke Endoh <[e-mail]> wrote:
> Hello,
>
> 2011/10/22 Luis Lavena <[e-mail]>:
>> But, this is a problem for more complex gems like EventMachine,
>> nokogiri and others that depend on externals (openssl, libxml2).
>
> Sorry I can't understand. =A0Why does it become more difficult if
> it depends on external library?
>

These gems depends on 3rd party libraries (OpenSSL, libxml2) which,
under the environment I'm worried about (Windows) are not present by
default.

This increases the burden on gem authors to compile binaries for every
new API version of Ruby.

>
>> 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.
>
> You mean "fat-binary" will become fatter to include binaries for
> 1.8, 1.9, 2.0.0, 2.0.1, ..., right? =A0Indeed it looks uncool, but
> so matter in practice? =A0Aren't Eric planning to address this issue?
>

See above, if gem authors don't do that, then installation of complex
gems like nokogiri, EventMachine with SSL support or others will be
complicated.

For every new Ruby version that changes ABI, gem authors will require
to release a newer binary that either bundles all the supported
versions of Ruby for his gem or drop those versions from the
dependency.

I believe what Eric will address is the be able to define a dependency
under which Ruby you can install certain gem.

>
>> While 1.8.x usage has been reduced lately, it is still present.
>
> Slightly off topic, 1.8 will be dying when 2.0.0 is released.
> (2.0.0 will be released at Feb. 2013, and 1.8 will be abandoned
> at June 2013) =A0So I don't feel like caring about 1.8.
>

1.8 is just an example, instead of 1.8 it will be come 1.9.1 versus
2.0.0 versus 2.0.1

Gem authors that want to support 1.9.3 and newer version of Ruby will
still need to compile their extension multiple times to be able to
generate fat-binary gems.

>
>> 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.
>
> Yes, in a sense, this proposal intends to move the overhead from
> the core team to gem authors. =A0I wonder if the overhead is too
> heavy or not. =A0I guess the 2.0.x will be released about once a year
> (or lesser frequent).
>

I think that will depend on what Eric comes up with.

Also will depend if the gem author wants to drop support for older
versions of Ruby.
--=20
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=E9ry