Re: Legacy support (Was: Base64 not there makes Rails 2.0.2 fail to load in 1.9.0)

Charles Oliver Nutter wrote:
> Richard Kilmer wrote:
>> I think it would be good to warn in 1.9 if the gem DOES NOT have the
>> required_ruby_version set (which most won't btw).  Warn that this gem
>> may not be compatible with Ruby 1.9.  It would also be helpful to have
>> this message at gem install time.  This is an annoyance, and like Dave
>> said, it will pressure people to update them, but at least we will
>> then know what gems are explicitly ready for 1.9.
> 
> I raised this question on the RubyGems list and didn't get the answer I
> hoped...so I reraise it here:
> 
> How should one create a gem that works on both 1.8 and 1.9 given such
> major changes as String M17N?
> 
> Or put another way...
> 
> Shouldn't there be a way to release two copies of a gem, same version
> number, but targeting different major Ruby versions?

Ouch ... there are already two different versions of gems with C
extensions in them, one with the C code for folks with compilers, and
one with the Windows-binary compilation done for them for folks with
Win32. And I have no clue what happens to someone with Win64. Of course
everything in Win64 is upward compatible from Win32, just like the check
is in the mail. :)

I guess the question someone who creates a gem has to be able to answer
is, "How many different platforms do I have to worry about?" Right now,
the "big three" are MRI on Unix/Mac, MRI on Windows and jRuby, but now
we have KRI on Unix/Mac and Windows, and I'm guessing jRuby 1.9 isn't
too far behind them. That's six, and when IronRuby and Rubinius get
finished, even if they are only running 1.8 syntax/semantics that's two
more.

So I guess I'd ask Eric and the other RubyGems developers, "just how
smart can a gem get? Can it figure out that it's running with MRI or KRI
on Windows and load the correct binary code, but recompile for MRI or
KRI on Unix/Mac? Can it detect jRuby and do the right thing there?"

Can this wait till Summer of Code? ;)

But seriously, folks, "configure" and all the mechanisms built around it
seem to be able to handle the bulk of such intricacies and do the right
thing, with the notable exception of using the Microsoft tools on
Windows. But an awful lot of this stuff "just works" on a Windows box
under Cygwin and MinGW as well.

How big is MinGW? Maybe the next version of the one-click installer
should go back to using MinGW and pull in the required run-time pieces
for building gems from C source if they aren't on the machine already.
That would make life a lot easier for Ruby programmers on Win32.

A lot of open-source installers for Windows do just that. For example,
the LyX document processor requires Python, Ghostscript, MikTex and a
few other things I've forgotten. When you install LyX, it checks your
system and if you don't have one of the dependencies, it goes out and
gets them.