Since I was pretty bored last night (my blog was down, and is up tentatively and temporarily until I can get my hands on a bigger vserver – and actually for me this time – so that I can the blog on its own system, and maybe use it as a mirror for xine’s bugzilla and site), I’ve found time to relax by writing a new Ruby eclass. This started as a way to actually support installation of Ruby packages for the newly-updated JRuby but quickly grew into some more interesting project.
The new eclass not only provides support for configurable, variable Ruby implementations (right now only Ruby 1.8, Ruby 1.9 and JRuby, more can be added) but also supports fake gems natively, which is important to avoid installing so many packages as gems (you remember why don’t you?) while not losing features. In particular, while I have been adding non-gems ebuilds with proper testing, there are a few issues with that method, starting from the fact you cannot slot packages, even when they should be installable side-by-side, like bluecloth or aws-s3.
The ruby-ng eclass, thus, installs tarballs in the same path and layout as real RubyGems, using a crafted fake gem specification, which provide the basic information needed for the them to be picked up. At the same time, though, it leaves the whole of the dependency tracking to Portage, like it should, and it allows for tests to be executed during merge so that you can be sure that the newly-installed code works.
It goes beyond this, though: the way the eclass is designed, you don’t install documentation more than once without reason (with the current eclass, data is copied for each implementation, even if just the last copy is the one that gets merged to the live filesystem), and you don’t extract the same tarball but once. Also, it doesn’t install the extra cruft that gems install (the copy of the gem archive itself, the tests, the unparsed, out of place documentation, the object files for compiled extensions, and so on so forth). The result is a pretty clean gem-compatible install, included binary commands wrappers — you get rake installed out of tarball, instead of gem!
As I said the implementations to install the Ruby extensions for are configurable, on a per-ebuild basis even, by using a new USE-expanded variable (for now called GENTOO_RUBYLIB because I was out of cool names to use, not definitive), and it makes heavy use of EAPI 2’s USE dependencies to bring in the libraries enabled for the right implementations, which is something that the previous code was pretty bad at. This means that both you can get a proper dependency tree for the extension, and repoman can make sure that you don’t commit something that is not supposed to work properly (like for instance a dependency is not supported for one of the implementations). And finally the actual used implementation is depended upon, which changes the paradigm of virtual/ruby tremendously: extensions should depend on the implementation they are built for and the virtual should only be used by scripts with no implementation-dependent libraries needed).
Right now it’s lacking documentation, polishing, and obviously approval for enter main tree. I hope we can coordinate on this in the next week or so, but it might take longer since I have absolutely no clue how this intersect and influences gemtoo. Also, it’s way far from complete, I haven’t worked on proper slotting yet, and I should try it with both Rails libraries and Rails plugins to make sure it works for those — it would be pretty darn nice if you could test the plugins on install finally!
Because I started working on this less than 24 hours ago, the interface is most likely deemed to change, so you should not rely on this for anything but a testbed; dependencies can be broken and stuff like that. On the other hand, once it’s actually implemented, I’ll see to spend my free time to port as much ebuilds as I can to the new format and eclass, so that we can get it running decently soon.
While the new interface is, to me, a lot simpler than the original ruby eclass, and thus the porting effort for non-gem ebuilds is quite negligible, I’d like to say that such a task is going to take a while, just like it took a while to our superb Gentoo Java team to work out the new Java eclasses, put them in production, and get rid of all the old eclasses and ebuilds and the old generation of Java support in Gentoo. On the other hand, what the Gentoo Java team achieved is that Gentoo is one of the best distributions to develop with Java on Linux (almost everything’s packaged); I wish before next fall people will be saying that Gentoo is the best distribution to develop with (and deploy) Ruby on Linux.
As an example of issues I’ve found and I know I’ll find many more times, there are packages that are not bumped in Gentoo and that probably should be together with the porting (so that the latest version, that hopefully works with Ruby 1.9 and all the other implementations we’re going to support, is used); there are packages that requires further packages to run their tests (I’ve said that before, but even today I had to spend most of my time packaging “RDoc 2” which is needed by BlueCloth to run tests… it won’t work with the current eclass so you won’t find it in Portage yet, but it’s in the testbed); there are packages whose tests are simply broken out of the imaginable (for instance Rake that fails its test on all three implementations; Ruby 1.8 and JRuby seem to only have minor issues, Ruby 1.9 seems strangely broken).
So I’ve talked this much about what I’ve been doing and what I hope to be able to do in the next week, but I haven’t shown you the code yet… well here it is; but be warned that you should not be using it unless you’re a Gentoo Ruby developer! But you can read it and thank me with a gift if you want…
Work’s not done yet, though.