[Rubygems-developers] The case of binary gems and Ruby versions.

Luis Lavena luislavena at gmail.com
Thu Apr 16 19:43:52 EDT 2009

On Thu, Apr 16, 2009 at 8:15 PM, Eric Hodel <drbrain at segment7.net> wrote:
> On Apr 16, 2009, at 03:11, Luis Lavena wrote:
>> Been investing a lot of time in Ruby 1.9 as I move forward for updated
>> RubyInstaller (One-Click) for both 1.8.6 and 1.9.x branches.
>> Because of that, I've started to realize, even more and more, that
>> distributing binary gems between versions is set to failure.
>> Let me explain my logic with a simple example.
>> My gem contains a extension, which I compile, cross-compile and
>> package for 'i386-mswin32' (x86-mswin32) using my stock Ruby 1.8.6
>> installation. I can also compile for the new RubyInstaller platform
>> (mingw32) using the same approach.
>> At the time I upload that to rubyforge, I upload the following files:
>> my-gem-1.0.gem
>> my-gem-1.0-x86-mswin32-60.gem
>> my-gem-1.0-x86-mingw32.gem
>> At this point, everything is good.
>> Since the last 2 gems listed there are binary gems, those will be
>> linking with msvcrt-ruby18.dll, which is the runtime library for Ruby
>> on Windows (both MinGW and VC6). No problem so far.
>> You wonder, where is the problem then?
>> These gem where built for 1.8, so installing those in 1.9 will not
>> fail unless I specify require_ruby_version (which is something
>> rake-compiler now does).
>> Now, the real problem becomes when I want to provide binaries for BOTH
>> ruby version, since RubyGems, besides the required_ruby_version don't
>> provide a mechanism to distinguish 1.8 from 1.9 gems, I end with the
>> exact same gem names, with the exact same versions and platforms, thus
>> overwriting previous versions.
>> Someone suggested me that release 1.0.0 for Ruby 1.8 and 1.1.0 for
>> Ruby 1.9, but that is misleading.
>> I think we reached the point where RubyGems roadmap needs to start
>> considering these cases to provide a more mature solution for us.
> I see two solutions:
> Package two separate gems with an indicator in the name for 1.8 vs 1.9

The problem is that indicating the version of ruby in the gem will not
make the installation easy.

> Package a gem with both libraries inside, and add something to require_paths
> for 1.8 vs 1.9
> I prefer the later, as it'll be easiest to implement even though it will
> increase the burden on the packager.

It will end being a huge problem.

What about adding officially support for gem-name-version-RUBY_VER-PLATFORM.gem

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