As for any other project involving a non-trivial effort, even the new Ruby eclasses (ruby-ng and ruby-fakegem), that I’ve started writing last May, will not bring only successes on the short term, but will also require some setbacks from time to time.
In this case, what is working out well is the new list of dependencies: we can easily make sure that all the packages that are needed for one extension to work are installed for the selected implementations. This really simplifies the amount of work both us and the users have to deal with when supporting multiple implementations.
What has been set back is proper, unmasked support for Ruby 1.9 and JRuby. The reasons for these setbacks are quite varied: we don’t have the latest version of JRuby available for instance (1.4 versus the 1.3.1 we have) because it fails its own tests; we’re also lacking the latest 1.9 version of MRI (the original Ruby that is), because Alex found a quite nasty segmentation fault (likely a race condition). But also some gems have broken tests that don’t take into account Ruby 1.9 behaviour, and others are simply broken with anything that is not MRI 1.8.
It’s interesting to note that while a lot of people insist that Ruby 1.9 is fine, even production ready, to the point that Daniel Robbins made it the default in Funtoo if I recall correctly, while even some pretty basic packages fail their tests badly when running (or built) against 1.9, including quite a few dependencies of Rails. And even when they have some kind of support for Ruby 1.9, they might uncover bugs from time to time.
One such case happened with ruby-prof: you might have noticed that it was bumped a couple of times in Gentoo in the last few days; the reason for that is that I was able to get upstream to fix up the tests so that they could be run with Ruby 1.9; while doing that, though, they found a bug in Ruby and after that, another one that Roger is still fleshing out for reporting.
For what concerns JRuby, the main problem as one might guess is interacting with native extensions: you cannot use native extensions directly in JRuby, obviously, since it’s written in Java. But you have some ways around that, as upstream reports: you can write a pure-Ruby implementation of your extension; you can use the dl extension to load a native library directly, to access its functions; or you can write the “native” part (which is usually the performance-bound part) in Java rather than C and get it to load a bytecode JAR as it was a native extension.
The problem here is that most of the developers out there are unlikely to pay equal attention to all the implementations, which often results in the “fallback” versions (pure Ruby and dl) to not be properly tested, if at all. And for those who do provide the Java-based code for their extensions, it gets even murkier. Some extensions only package in the gem the sources for either MRI (and compatible) and JRuby, and so you can’t just use one gem and build for both implementations (this is the case of Redcloth which is even further complicated, see later on). Others only package the pre-built jar file, and not the sources, in the distributed tarball. Others again, like it’s the case for rcov, ship with a pre-built jar and the sources, but trying to build the new jar fails badly. But it doesn’t stop there, as things are complicated by a lot of developers still only using Ruby 1.8.6 rather than 1.8.7 (which presents different failures, for instance with rcov again).
With Redcloth, the case is even worse: like Bluecloth, the modern extension can make use of a Ragel-based parser. It turns out that I’m one of the two maintainers in Gentoo for Ragel (because of feng ) so I would have no problem with making sure that it would be able to rebuild the parsers (eventually providing options to choose the method for the state machine generation). Unfortunately the source Ragel files (.rl) are missing both on the downloadable packages (gem and tarball) and on the GIT repository (which is pretty nasty). I tried contacting the author via twitter (given I couldn’t get a mail) but I have had no answer yet in about ten days.
But this is all talking about the setbacks; some success are, though, present, which is actually the only way I could be writing this here, now. Yes, because to make sure that the new fakegem-based ebuilds do work fine in production, my blog is moving to the new ebuilds as they come available. And today in particular, I put in production both the new ActiveRecord (and ActiveSupport) ebuilds, but also a new package: dev-ruby/pg that took the place of dev-ruby/ruby-postgres.
So if you can read this post, it means that my setup works, and thus that the ebuild we’re working on are not totally broken. And this, in my book, counts as success.
