[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
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