[gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hey all -- so I've noticed that there are a lot of packages using
python-single-r1.eclass which are python-2 only -- ie PYTHON_COMPAT=(
python2_{6,7} ) in most cases.  Effectively this means either an
end-user needs to tie PYTHON_SINGLE_TARGET on their system to
"python2_7", or they need to set the flag explicitly through
/etc/portage/package.use all the time.

As python-single-r1.eclass is meant to ensure that a package is bound
to just one implementation when multiple implementations are possible,
usually because it is too difficult to make the package multibuild, it
would make sense to me that if there is actually just one possible
implementation an ebuild can be satisfied with regardless of the
PYTHON_TARGETS and PYTHON_SINGLE_TARGET selections, that the ebuild
should be able to just depend on and use it regardless of what
PYTHON_SINGLE_TARGET is set to globally.

Simple example of situation -- assuming a properly-written
distcc-3.1-r9.ebuild (which the in-tree version apparently isn't):

> PYTHON_TARGETS="python2_7 python3_3 python3_4" \
> PYTHON_SINGLE_TARGET="python3_3" \ emerge -av sys-devel/distcc
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies |
>
> !!! Problem resolving dependencies for sys-devel/distcc ... done!
>
> !!! The ebuild selected to satisfy "distcc" has unmet
> requirements. - sys-devel/distcc-3.1-r9::gentoo USE="gtk -avahi
> -hardened -ipv6 -selinux -xinetd" ABI_X86="64"
> PYTHON_SINGLE_TARGET="-python2_7" PYTHON_TARGETS="python2_7"
>
> The following REQUIRED_USE flag constraints are unsatisfied:
> python_single_target_python2_7
>
> The above constraints are a subset of the following complete
> expression: python_single_target_python2_7? (
> python_targets_python2_7 ) exactly-one-of (
> python_single_target_python2_7 )


There are two ways to deal with this in-ebuild -- the first would be
to adjust the ebuilds to python-r1 but not multibuild them, which
means that the ebuilds are python-single but not actually implemented
in a python-single way.  The other is to adjust python-single-r1 so
that if there is only one possible implementation (ie, PYTHON_COMPAT
just has one entry, or only one such entry is in _PYTHON_ALL_IMPLS)
then the PYTHON_SINGLE_TARGET setting is ignored.

The main issue that this may cause is that the python_single_target_*
use dependencies are no longer fully deterministic at all times, and
are rather now determined based on the supported python implementation
list in _python_impl_supported() from python-utils-r1 -- ie, when that
list changes, some packages may suddenly require PYTHON_SINGLE_TARGET
be set while others just-as-suddenly won't need it.  This may mean
some extra rebuilds for users on "emerge -N", especially as the flags
are dropped.

Please note that documentation is likely going to need updating; I
tried but more work is going to be required on that front.  The eerror
section at the bottom of python-setup is particularily nasty and
likely needs adjusting.  Otherwise though, functionality seems to work
as expected without any side-effects in my 10 minutes of testing.

Thoughts and feedback appreciated -- I think incorporating this will
really help out end-users that don't want to remain locked to python-2.7


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlRRLzkACgkQ2ugaI38ACPBnPQEAmq0mB+jzbKc/M2y971d5SdvV
+jFtXvJgWEmKMbABKQsBALImzNqOBirDomrPYrYLHc/JeblZUkWvVwNkQMZ3Qwyl
=T/jY
-----END PGP SIGNATURE-----