On Thu, Sep 9, 2010 at 3:25 PM, Roger Pack <rogerdpack2 / gmail.com> wrote:
>>> The biggest one I can think of currently is that rubygems *doesn't
>>> support* gems that are targeted at specific runtimes. =A0For example yo=
u
>>> cannot specify that gem "x" applies only to ruby 1.9 and greater.
>>
>> that is not true, see required_ruby_version.
>
> Well, not *entirely* true, apparently.


You're ignoring for a second that we are talking about Ruby 1.9 and
its standard library. Components gemmified from this will have
required_ruby_version >=3D 1.9.x, turning not possible for Ruby 1.8.x
use these gems.

>
>>> This also causes odd failures when using 1.9 on windows, because if
>>> you do a "gem install win32api" it ends up installing a gem that has
>>> binaries compiled only compatible with 1.8, so it fails at runtime.
>>
>> I believe those are separate things, those issues can be solved with
>> fat-binary gems or compiler been available for Windows users.
>
> To me it feels like more of a work around than a solution. =A0Plus I'm
> not sure that fat-binary gems would be an ideal way to distribute std
> libs.
>

fat-binaries is a workaround to binary gems on Windows where compilers
are lacking. that stays true for any platform that distributes gems in
binary form.

But again, we're talking about 1.9.x, so fat-binaries is not even
worth mentioning.

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