In my previous post where I declared myself up for hiring by those who really really want Ruby 1.9 sooner than we’re currently planning to release it, I’ve said that the Ruby team doesn’t want to “Pull a Python 3”. I guess that I should explain a bit what I meant just there.
Ruby 1.9 and Python 3 are, conceptually, actually similar: while Python 3 actually make a much wider change in syntax as well as behaviour, both requires explicit, often non-trivial, porting of the software to work. Thus, they both require you to be slotted, installed side-by-side, with the older, more commonly used alternative, and so do the libraries and programs.
There is more similitude between the way the two are handled than you’d expect, mostly because the Python support for that has been partly copied out of Ruby NG stripped of a few features. These features are, for the most part, what I’d say protect us from pulling a Python 3.
As it is, installation of Python 3-powered packages is done once Python 3 is installed; and Python 3 is installed, unless explicitly masked, on every system, stable or not, because of the way Portage resolves dependencies. In my case, I don’t care about having it around, so it’s masked on all my systems (minus the tinderbox, for obvious reasons). You cannot decide whether a given package is installed for 2.6, 2.7 or 3.1, and you can only keep around safely one Python for the 2.x series as it will only install for that — which is going to be fun, because 2.7 seem to break so many things.
Ruby packages instead is coordinated through the use of the RUBY_TARGETS variable, that allows us (and you) to choose for which implementation (if supported) install a given package; you can even tweak it package-per-package via package.use! This, actually, makes the maintenance burden quite higher on our side because we have to make sure that all the dependency tree is up-to-date with a given target, on the other hand though it allows us be sure that the packages are available, and it would scream at us if they weren’t (or rather Mr Bones would).
Most importantly, we don’t need no stinkin’ script like python-updater to add or remove an implementation; since the implementations are user-chosen via an USE-expanded variable (RUBY_TARGETS as I said), what you otherwise do with python-updater (or even perl-cleaner) is done through …. emerge -avuDN world.
Even though, I’ll admit, there is one thing that at least python-updater seems to take into consideration and that for now we can’t cater: using the Ruby interpreter rather than binding a library to be usable via Ruby; as I said in the post I linked above, it’s one of the few cases that needs to be kinked out still before it can be unmasked. Again you can either wait or hire somebody to do the dirty job for you.
A note about the “stinkin’ script” notion: one of the reason why I dislike the python-updater approach is that it lists a few “manual” packages to be rebuilt. The reason for that to happen is the old Python bug that caused packages to link the Python interpreter statically. The problem has since been fixed, but the list (which is very limited compared to what the tinderbox found at the time), is still present.
It is not all. I said at the start that right now Python 3 is installed unconditionally by default on all systems; we’re going to do double- and triple-work to make sure that the same won’t happen with Ruby 1.9 until we’re ready to switch the defaults. Switching the defaults will likely take a much longer time; we’re going to make 1.9 stable first, and start stabling packages supporting that… from there on, we’d be considering removing packages that are 1.8-only.
Well, to be honest, we’re going to consider switching some packages that won’t work with 1.9 (or JRuby) and neither have use nor they are maintained upstream. For good or bad, a lot of the packages in the tree have been added by the previous team members, and they, like us, often did so when they had a personal interest in the package… those packages often times are no longer maintained and are dead in the water, but we still carry them around.
Anyway, once again, the road is still bumpy, but it’s not impossible; I’m not sure if we can get to unmasking it before end of the summer as I was hoping to, but we’re definitely on track to provide a good user experience for Gentoo users who develop in Ruby, and most of the time, we can even provide a better upstream experience.
This post contains some factually incorrect informations related to Python.The code in python.eclass was designed almost fully independently of ruby-ng.eclass. Only idea of python_copy_sources() was partially based on a function from ruby-ng.eclass. python.eclass currently only doesn’t handle dependencies between Python packages. In other areas, python.eclass has more functionality than ruby-ng.eclass. E.g. python.eclass supports packages with optional building/installation of Python bindings (e.g. sys-fs/ecryptfs-utils).You CAN decide whether a given package is installed for 2.6, 2.7 or 3.1 by setting USE_PYTHON variable in /etc/make.conf. Setting USE_PYTHON=”2.6 2.7 3.1″ will cause installation for Python 2.6, 2.7 and 3.1. (Remember to run python-updater after changing USE_PYTHON variable 🙂 .)dev-libs/boost was in the manual list in python-updater, because /usr/lib/libboost_python*.so use (still now) symbols from libpythonX.Y.so without linking against libpythonX.Y.so. This problem will be fixed differently in python-updater-0.9. (I don’t know why 3 other packages are in the manual list. All 4 packages were added to this list by previous maintainers of python-updater.)
@ArfreverThere is one fundamental problem with USE_PYTHON – value is hardcoded in ebuild therefore user (or python_updater for that matter) doesn’t know whether value changed. Hell, even dependency system doesn’t have a clue about python ABIs. In ruby-ng one can USE depend on bindings for particular ruby version as last resort.This all causes famous issues with the need to manually run python-updater while this should not be needed in first place! That being said whole concept with python-updater is fundamentally broken by design.Stabilizing python3 while having python-updater issue unresolved (yes, existence of python updater is unresolved issue itself) was most irresponsible.
Err, “USE_PYTHON – value is hardcoded in ebuild therefore user (or python_updater for that matter) doesn’t know whether value changed” – I’m wrong here of course, but the rest stands.
@arfie: you’re sidestepping that USE_PYTHON isn’t actually exposed to the manager, meaning the resultant deps are loose/wrong (this is provably the case).So no, USE_PYTHON isn’t an equivalent of ruby targets (which actually integrates into the deps properly).