Friends!

The current state of python-single-r1 bothered me a lot lately,
and while _AxS_ did some neat improvements to the eclass, it's still
far from perfect solution to our users.

The PYTHON_SINGLE_TARGET flags were added to make it easier to handle
single-impl packages that support both Python 2 & Python 3 which we
enable both in our profiles. It serves that purpose well -- however, it
isn't that good for single-impl packages that don't support the most
common choice of implementations.

In particular, it has two major issues:

1. We have no sane, clear and universal way of providing users with
sensible defaults. It's always one trade-off over another.

2. Matching USE dependencies against multi-impl packages introduces
a second set of USE flags (PYTHON_TARGETS) that are semi-virtual.
Sadly, they introduce confusion and cause issues.


As far as the first issue is concerned, I think enough has been said
already. Right now we are fine-tuned for two cases:

a. packages that support one impl only -- then they have a single
PYTHON_TARGET that's enabled by default,

b. packages that support python2.7 -- then we have the profile default
of python2.7 for them.

We have no good way of handling packages that support Python 3 only.


The other issue comes into game in two cases I've seen:

A. when we try to improve setting of PYTHON_SINGLE_TARGET, we force
the user to enable matching PYTHON_TARGET anyway -- so in the end
manual intervention is required,

B. they cause issues with REQUIRED_USE on other packages (like libpeas
that supports only one version of python2 and one of python3). Even
though PYTHON_SINGLE_TARGET results in effective use of a single impl,
PYTHON_TARGET USE-dep requests full PYTHON_TARGETS match on the dep.
Therefore, the user needs to disable other implementations anyway to
get the expected result.


To be honest, I don't see a good way out of this. Possible bad ways:

I. disable PYTHON_SINGLE_TARGET and use PYTHON_REQUIRED_USE="^^ ..."
when python2_7 is not in PYTHON_COMPAT. In other words, add another
workaround that gets things rolling with the default profile setup.

II. Remove PYTHON_SINGLE_TARGET completely and use
PYTHON_REQUIRED_USE="^^ ...".

Option (1) is 'uglier' since it introduces another special case
and adds to the complexity. However, it supposedly impacts the lowest
number of users -- the default profile settings should pass, and only
people enabling more implementations would have to disable the flags.

Option (2) is cleaner but it imposes a major shock to our users. It
specifically involves manipulating USE flags on a lot of packages even
with the default profiles.

Both options come with another major drawback -- exactly-one-if deps
force manipulating the flags. Once manipulation is done, it may make
Python upgrades much harder -- esp. if portage would end up enabling
older impls via p.use.

Of course, this wouldn't be a problem if users only added -flags to
disable the old implementations. Then the issue will reapply when a new
implementation is enabled globally, making the effective of 2 enabled
implementations.


So, what are your thoughts? What are your solutions?

-- 
Best regards,
Michał Górny