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

On Dec 27, 2007 5:13 PM, M. Edward (Ed) Borasky <[e-mail]> wrote:
> 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. :)
>

Ruby mswin32 will work on Win64, using WOW (Windows On Windows) 32bits
emulation.

There is a x64-mswin64 build with VC8, but all the major gnu utils
will not work (readline, iconv, gettext) since they need a LOT of
tweking to get them working with VC8 32bits, now multiply it by 100
for 64bits).

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

MRI and KRI should be considered the same. jRuby and Rubinius will
implement the specs of these. IronRuby too (but didn't check the
project too close to confirm).

Platforms aren't "language implementations". Platforms are OS,
language implementation or "syntax variations" that a coder should
need to support is quite different.

1.9 is not quite different from 1.8, all major stuff of 1.8 will work
out of the box on 1.9, but the new "fancy" stuff 1.9 provides will not
be portable back to 1.8.

A developer should follow good practices instead of depend on language
to resolve their bad habits.

> 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?"
>

Mmm, binary? why binary? almost all the extension will compile without
too much tweking, if developers have taken care of some deprecations
like RSTRING(x)->ptr for RSTRING_PTR(x)

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

I don't know of what configure are you talking about: there is a
win32/configure.bat file for MS tools, in the same fashion of
configure.

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

Shhh, don't say that too loud! :-D

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

Some installers are too "clever", so clever that you always need
internet connection ;-)

Anyway, is no the case we are dealing right now.

The problem is that lot of new users are jumping to 1.9 and they
expect will replace 1.8, breaking their setups.
This is mostly due the huge amount of articles about performance enhancements.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams