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!
Amazing work!I’m truly impressed by the (rapid) improvement and very grateful for your attention and work for getting so much Ruby stuff into the tree (not to mention everything else you do for Gentoo, tinderbox and QA in particular!).Somewhat unrelated, but following your saga, I have a dream of someday having a similarly robust environment for Mono/.NET development on Gentoo as well. Given that the dotnet overlay seems to have fallen quiet and #gentoo-dotnet is a deadzone, any ideas or pointers about where to poke (I’d be more than happy to do the work if I got a bit of direction!) to improve that situation?
Will it be possible to have 2 (or more) ruby targets at the same time (I understend so but I prefere to ask)? If yes that’s great. I may even come back to ruby (I stopped when I tried to figure out how to test on JRuby).
Thanks Matt 🙂 As for dotnet, I don’t really know what to answer you. I know Peter was handling it single-handedly, but I haven’t seen him in the past few months. With the momentum generated by “the un-split of poppler”:http://ben.liveforge.org/20… (which was also Peter’s doing), I’m sincerely tempted to go on and do a gtk-sharp un-split as well. I actually have un-split ebuilds for gtk-sharp, gnome-sharp and gnome-desktop sharp locally, but there are a few problems with that as well: * gnome-desktop-sharp was the one with most sense to be split as the packages are mostly independent, and pull in components that are quite optional; * unsplitting gtk-sharp has the half-nasty effect of dropping the availability of the standalone glib-sharp package, which does not require X by itself (although I wouldn’t be able to tell if it worked before as it should have).Since I’m currently occupied with job-related tasks, and taking care of Ruby in the time I’m not working, it’s difficult for me t solve those two problems, and thus make it available for now. I hope to find time for that in the next few weeks.Maciej, @RUBY_TARGETS@ is definitely non-exclusive, that’s the whole point of it. So you can have packages installed for all the implementations that are supported at the same time, the only tricky part is that you’ve got to rebuild the package for all of them at the same time, but that’s a small price to pay, I’d say. Right now, the only targets “readily available” are Ruby 1.8 and JRuby, as Ruby 1.9 is currently masked away, but it takes just a moment to unmask Ruby 1.9 package and support. In the future, we most likely will support more targets, Ruby EE (in its two flavours) is the next possible target, but I wouldn’t dislike having a IronRuby target at some point.
is it possible to have the FOO_TARGET also for the python and mono environments?p.s.: I can contribute to the mono effort if there is approval of the TARGET system by the Gentoo mono project.
For Python, I don’t see that’s going to work given that Ruby-NG was almost ready by the time the new Python eclasses were written, and it seems clear that they decided on ignoring the “over-complex” complete dependency handling which is the basis for which Ruby works.As for Mono, I’m not sure which other currently-available implementation is there, to be honest. Multiple Mono versions at the same time, should most likely work with the same installed code. On the other hand, Mono really needs a overhaul. Currently we patch both Mono and the various build systems to install the PE files in @/usr/lib64@ out of the chance that, in the future, we’ll be supporting Ahead-Of-Time recompilation into arch-native code. My suggestion for this is to either implement that or *stop fiddling with upstream choices*.
Awesome work indeed! It’s sad that with things like perl and ruby, gentoo is becoming years behind where it should be (even on its unstable branch).