[gentoo-python] python-r1 <-> python.eclass package dependencies

[Michał Górny]

Hello,

As some of you are aware already, there is a significant difference
in handling Python implementation choice between python.eclass
and python-r1 / p-d-ng.

The python.eclass packages use USE_PYTHON (undocumented variable)
or the eselected Python2+3, and store that choice implicitly.
Everything works on the assumption that implementations don't change
or user runs python-updater.

The python-r1 / p-d-ng packages use explicit USE flags to choose
implementation. The choice is thus explicitly exported and other
packages can use USE dependencies to enforce matching implementations.

The problems arise whenever python-r1 package depends on package using
the python.eclass, or the other way round. There is no clear way to
enforce the same implementations being used, so everything falls down
to user.

In order to solve the most common problems due to that, I have
published a news item explaining how PYTHON_TARGETS work and what needs
to be done with them.

In the discussion with other Gentoo Python devs, it was assumed that
USE_PYTHON should not be considered public and thus not be described
in the message. Sadly, it seems that this resulted in people actually
trying to disable Python3 using PYTHON_TARGETS and seeing random
failures due to python.eclass enforcing it anyway.


I believe we should thoroughly think what should be done now in order
to solve the issues best for the transition time. Here are a few
solutions I can think of.

1) lard both eclasses with USE_PYTHON <-> PYTHON_TARGETS consistency
checks. This should be pretty easy for python-r1, harder for
python.eclass (anyone volunteering to touch it in thick gloves?).

In other words, we just warn users whenever they need to do something
to ensure things work.


2) make python.eclass respect PYTHON_TARGETS.

Sadly, due to PMS limitations we can't tell if PYTHON_TARGETS was set
by user or has the default value. So we either can:

a) stop using USE_PYTHON and eselect defaults, start using
PYTHON_TARGETS only, pull in correct Python versions, tell users to run
python-updater;

b) prefer PYTHON_TARGETS over USE_PYTHON and the default (but only
if PYTHON_TARGETS != default PYTHON_TARGETS, so we're on thin ice here).


3) make python.eclass respect and export PYTHON_TARGETS in IUSE.

Like the above but instead of running the fragile and broken
python-updater, we simply force rebuild of all packages. People can
start using USE-deps in the meantime, everyone becomes a bit happier
in the further plane. Sadly, this means every Python package is going
to need being rebuilt.


Please also note that 2 & 3 mean mass-changing behavior of stable
packages. Not something I'd do in a short timeframe where the issue
should be best fixed.

Any other ideas? Any +1, -1s?

-- 
Best regards,
Michał Górny