Ruby-NG: The Most Ebuilds

This is a merry time for the Gentoo Ruby team, and for the users and developers of Ruby in Gentoo! As of last night, I have confirmed that there are more ebuilds in tree using the new Ruby-NG eclasses (ruby-ng.eclass and ruby-fakegem.eclass) than there are using the old style ones (ruby.eclass, gems.eclass)! This is thanks to Alex and Hans who have been doing overtime to work on bumping the new packages.


Feel free to compare to the original charts even though they are of different types.

I have sampled the past nine days, at the end of each day, to get some more interesting charts. The first thing that might be obvious by those is that the amount of Ruby ebuilds in tree is increasing with the new eclasses: it’s mostly related to our need for new dependencies, usually for tests (since we never run them before, those dependencies often were ignored altogether), but it doesn’t stop there, as I for instance have added a few more for my own consumption.

The other graph also shows a pretty interesting situation: JRuby support is reaching Ruby 1.9! While all the packages using compiled C extensions are to be left alone (unless, of course, they have an equivalent Java extension), there are more than a couple of packages that fail with Ruby 1.9 because of the changes in the syntax but work with the current JRuby — since it defaults to 1.8… I’m not sure how I’m going to work this around when the default will be 1.9, nor I have no idea how to properly support the fact that it can switch the two implementations, for now… maybe we’ll end up having jruby18 and jruby19 targets at some point).

Now, if headius were to give me a working Duby, I would be able to add at least three packages that are JRuby specific, and with the current situation, that would mean more JRuby packages than Ruby 1.9 packages, as easy as that. And by the way there is one thing that I would like to point out, regarding JRuby support. The way we implemented Ruby-NG in Gentoo, it means that we’re not bound by gems declarations, dependencies, or whatever else, as we can sidestep all of it, eventually patching the code (as I did before for shotgun not to require launchy). The end result is that the instructions on how to set up ruby-debug on JRuby, are not relevant to us: RUBY_TARGETS=jruby emerge ruby-debug will take care of everything for you, including installing the alternative gem! And similarly, we’ll never hit the problems with ActiveRecord as the various implementations are separate.

So anyway, back to work to make Gentoo even better for Ruby development and use!