Hacking is easy…

… un-hacking definitely not.

Since both Zeno and Jeremy reported a few things about rubygems lately, I ended up deciding to take a look at the rubygems code and see if it was possible to un-hack it so that, from one side, it follows upstream more closely, and from the other, it actually works in Gentoo without risks.

Now, Gentoo has currently a number of hacks over Rubygems (the library, and the package manager) for two main reason: supporting the Portage-based install of gems in the old manner (as in calling gem from within the eclass), and supporting multiple Ruby implementations to be installed at the same time.

For what concerns the fist case, thanks to RubyNG we no longer need the hacks at all, and so we can drop them (and fix the dependencies so that the new, unhacked version is not brought in with any of the old versions).

And luckily for me, even the multi-Ruby support is now getting reduced; in particular now 1.8 and 1.9 (from 1.9.2_rc2 onward) install in the same sub-tree (/usr/lib/ruby) rather than in two separated. Less fortunately, Ruby Enterprise still install in a quite different tree (/usr/lib/rubyee) so it still requires changes.

More importantly, now the installation to /usr is handled through Portage, so Rubygems would have to install on a different tree, such as /usr/local; to do that, it requires some changes around the paths and.. doesn’t that sound like hacking and patching? Well, I have to say this about the current Rubygems developers: they thought about it already!

So indeed, we can install our own default configuration replacement that can be used to set up default search paths and so on so forth. Good! Almost perfect, almost because it still has one /etc hit hardcoded that we’d have to change for prefix support, but I have a patch to be sent upstream that should be acceptable to them as well as usable for us. By using this, we can also avoid two implementation-dependent patches… and I have to tell you this: implementation-dependent patches suck, and will suck even more when we’ll have filesystems capable of runtime data de-duplication — and for archives.

For the next part of the complexity issues, you have the current install phase, that actually relies on the Rubygems’s own install code, which then requires a number of directories to be created beforehand and so on, so forth. The solution now is simply to hand down the installation to ruby-ng.eclass which simplifies it a lot.

But since I’m doing radical changes to the Rubygems installation we had before, I thought it would have been a good idea to do something that up to now has been ignored: adding the tests; Rubygems is said to need itself to actually work… in truth what it needs is Rake… and a few more gems that do require it to be installed. Oh well, once again we can do that nowadays, so I wired up the tests; beside one test (the one checking for bindir) being totally bogus, as it fails as soon as you rewire that path, the tests worked not-too-fine-but-well-enough on Ruby 1.8, and 1.9. JRuby was another story altogether.

The problem with all the implementations’ tests is that they are actually incompatible with a few gems, such as YaRD (because it tries to replace RDoc, and Rubygems tests RDoc) and Test::Unit 2 (that’s actually very very common). Given that I actually care about running these tests, the solution has been to simply… block on the presence of those two. This is something that we’ll be doing on more ebuilds until we can work out a solution; most people wouldn’t have Test::Unit 2 merged for development (my suggestion on how to write tests? Use RSpec! Or Tryouts 2… both have the same implementation on both Ruby 1.8 and 1.9, while minitest and test-unit both have different, not-entirely-compatible, implementations), so it’s acceptable.

For what concerns JRuby in particular, though, the problem runs much deeper; so many tests fail that it’s not even funny, but it seems like the same is true for the vanilla version; at least two of the failures I found are related to the code that JRuby inject (with the same support that allows us to load Gentoo-specific configuration), which changes the original behaviour of the library, possibly trying to improve it, but as it is, most likely breaking the intended behaviour. Having to back-patch this, is definitely a bit tricky.

But the unhacking does not stop here, since I had to install Ruby-Enterprise, and it does not build with SSL enabled, I ended up noting that there are a number of packages that require the interpreter to be built with SSL support, and right now we have no way to express that. I guess we’ll get a new-style virtual/ruby this week.

Alas.