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

Luis Lavena luislavena at gmail.com
Thu Apr 16 20:33:21 EDT 2009


On Thu, Apr 16, 2009 at 8:53 PM, Daniel Berger <djberg96 at gmail.com> wrote:
> Eric Hodel 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
>>
>> Package a gem with both libraries inside, and add something to
>> require_paths for 1.8 vs 1.9
>
> Could this be automated somehow? Can we dynamically set the linkage within a
> gem on Windows based on the version of Ruby that's running it?
>

The extension link to so many different functions inside libruby that
perform the linkeage is kind of impossible.

An alternative will be build two versions of the same extension
(my_ext18 and my_ext19) and load it accordingly, but that's another
compilation complication that developers will need to work out.

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


More information about the Rubygems-developers mailing list