[gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[Ian Stakenvicius]

[-- Attachment #1: Type: text/plain, Size: 3532 bytes --]

-----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-----

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 4314 bytes --]

--- python-single-r1.eclass	2014-10-29 12:59:38.000000000 -0400
+++ /tmp/python-single-r1.eclass	2014-10-29 12:19:23.000000000 -0400
@@ -136,8 +136,9 @@
 
 # @ECLASS-VARIABLE: PYTHON_REQUIRED_USE
 # @DESCRIPTION:
-# This is an eclass-generated required-use expression which ensures the following:
-# 1. Exactly one PYTHON_SINGLE_TARGET value has been enabled.
+# This is an eclass-generated required-use expression which ensures the following
+# when more than one python implementation is possible:
+# 1. Exactly one PYTHON_SINGLE_TARGET value has been enabled
 # 2. The selected PYTHON_SINGLE_TARGET value is enabled in PYTHON_TARGETS.
 #
 # This expression should be utilized in an ebuild by including it in
@@ -155,22 +156,21 @@
 # ^^ ( python_single_target_python2_6 python_single_target_python2_7 )
 # @CODE
 
+# @ECLASS-VARIABLE: _PYTHON_SINGLE_TARGET_INUSE
+# @INTERNAL
+# @DESCRIPTION:
+# This is a read-only variable which is set when it is determined
+# that there is more than one possible supported python target,
+# and so the PYTHON_SINGLE_TARGET use-expand will take effect.
+
 _python_single_set_globals() {
 	local impls=()
 
+	_PYTHON_SINGLE_TARGET_INUSE=0
 	PYTHON_DEPS=
 	local i PYTHON_PKG_DEP
 	for i in "${PYTHON_COMPAT[@]}"; do
 		_python_impl_supported "${i}" || continue
-
-		# The chosen targets need to be in PYTHON_TARGETS as well.
-		# This is in order to enforce correct dependencies on packages
-		# supporting multiple implementations.
-		PYTHON_REQUIRED_USE+=" python_single_target_${i}? ( python_targets_${i} )"
-
-		python_export "${i}" PYTHON_PKG_DEP
-		PYTHON_DEPS+="python_single_target_${i}? ( ${PYTHON_PKG_DEP} ) "
-
 		impls+=( "${i}" )
 	done
 
@@ -182,11 +182,34 @@
 	local flags=( "${impls[@]/#/python_single_target_}" )
 
 	local optflags=${flags_mt[@]/%/(-)?}
-	optflags+=,${flags[@]/%/(+)?}
 
-	IUSE="${flags_mt[*]} ${flags[*]}"
-	PYTHON_REQUIRED_USE+=" ^^ ( ${flags[*]} )"
-	PYTHON_USEDEP=${optflags// /,}
+	if [[ ${#impls[@]} -eq 1 ]]; then
+		# One implementation, don't set python_single_target* in IUSE
+		# and set deps directly according to value of ${impls[@]}
+		IUSE="${flags_mt[*]}"
+		PYTHON_USEDEP=${optflags// /,}
+		python_export "${impls[@]}" PYTHON_PKG_DEP
+		PYTHON_DEPS="${PYTHON_PKG_DEP} "
+		_PYTHON_SINGLE_TARGET_INUSE=1
+	else
+		# Multiple possible implementations, prepare deps and IUSE
+		# for inclusion of python_single_target*
+		for i in "${impls[@]}"; do
+			# The chosen targets need to be in PYTHON_TARGETS as well.
+			# This is in order to enforce correct dependencies on packages
+			# supporting multiple implementations.
+			PYTHON_REQUIRED_USE+=" python_single_target_${i}? ( python_targets_${i} )"
+
+			python_export "${i}" PYTHON_PKG_DEP
+			PYTHON_DEPS+="python_single_target_${i}? ( ${PYTHON_PKG_DEP} ) "
+		done
+
+		optflags+=,${flags[@]/%/(+)?}
+
+		IUSE="${flags_mt[*]} ${flags[*]}"
+		PYTHON_REQUIRED_USE+=" ^^ ( ${flags[*]} )"
+		PYTHON_USEDEP=${optflags// /,}
+	fi
 
 	# 1) well, python-exec would suffice as an RDEP
 	# but no point in making this overcomplex, BDEP doesn't hurt anyone
@@ -216,6 +239,17 @@
 	local impl
 	for impl in "${_PYTHON_ALL_IMPLS[@]}"; do
 		if has "${impl}" "${PYTHON_COMPAT[@]}" \
+			&& [[ ! ${_PYTHON_SINGLE_TARGET_INUSE} ]] \
+			&& use "python_targets_${impl}"
+		then
+			# Only one implementation possible since
+			# _PYTHON_SINGLE_TARGET_INUSE is false,
+			# enable it explicitly
+			python_export "${impl}" EPYTHON PYTHON
+			python_wrapper_setup
+
+		elif has "${impl}" "${PYTHON_COMPAT[@]}" \
+			&& [[ ${_PYTHON_SINGLE_TARGET_INUSE} ]] \
 			&& use "python_single_target_${impl}"
 		then
 			if [[ ${EPYTHON} ]]; then
@@ -243,12 +277,21 @@
 
 	if [[ ! ${EPYTHON} ]]; then
 		eerror "No Python implementation selected for the build. Please set"
+		if [[ ${_PYTHON_SINGLE_TARGET_INUSE} ]]; then
 		eerror "the PYTHON_SINGLE_TARGET variable in your make.conf to one"
 		eerror "of the following values:"
 		eerror
 		eerror "${PYTHON_COMPAT[@]}"
 		echo
 		die "No supported Python implementation in PYTHON_SINGLE_TARGET."
+		else
+		eerror "the PYTHON_TARGETS variable in your make.conf to include one"
+		eerror "of the following values:"
+		eerror
+		eerror "${PYTHON_COMPAT[@]}"
+		echo
+		die "Only supported Python implementation not in PYTHON_TARGETS."
+		fi
 	fi
 }
 

Re: [gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

On Wed, Oct 29, 2014 at 02:17:29PM -0400, Ian Stakenvicius wrote:
> 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…

I understand “It's too difficult for me to get this build system to
work with multiple Python versions.”  I'm skeptical that there are any
packages where “there is actually just one possible implementation.”
Still I agree that some users will want a way to say “if I ask for a
package that only installs for one Python implementation, just install
it without my needing to tweak my USE flags.”

Personally, I'd prefer to stick with my existing PYTHON_SINGLE_TARGET.
If a package doesn't like that, I can think harder about whether or
not I actually need the package.  My Docker images [1], for example,
are single-Python implementations and I don't want to pull in another
Python accidentally.

Cheers,
Trevor

[1]: https://github.com/wking/dockerfile

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2226 bytes --]

Dnia 2014-10-29, o godz. 14:17:29
Ian Stakenvicius <axs@gentoo.org> napisał(a):

> > 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.

This is an easy way to get package broken once someone adds python3
support.

>  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.

This is ugly.

I was rather thinking of making all eclasses put +impl in IUSE when
only one implementation is supported.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[Ian Stakenvicius]

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

On 29/10/14 02:31 PM, Michał Górny wrote:
> 
> This is ugly.
> 
> I was rather thinking of making all eclasses put +impl in IUSE when
> only one implementation is supported.
> 

...how would that work?  PYTHON_SINGLE_TARGET as set in make.conf
overrides the +impl in IUSE.


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

iF4EAREIAAYFAlRRNHgACgkQ2ugaI38ACPA/8wD8CLNKuAi1V3IQwhcpbUFwe5En
/9jw0P9mBUr/CdZPY6kA/2cFyuGwLaMUANuQvKx9PTlB05F9P0kMCWjVlmXItOkd
=Aq7B
-----END PGP SIGNATURE-----

Re: [gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[Ian Stakenvicius]

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

On 29/10/14 02:25 PM, W. Trevor King wrote:
> On Wed, Oct 29, 2014 at 02:17:29PM -0400, Ian Stakenvicius wrote:
>> 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…
> 
> I understand “It's too difficult for me to get this build system to
> work with multiple Python versions.”  I'm skeptical that there are
> any packages where “there is actually just one possible 
> implementation.” Still I agree that some users will want a way to 
> say “if I ask for a package that only installs for one Python 
> implementation, just install it without my needing to tweak my USE 
> flags.”

There's a ton of packages that are only python2 -- that is, have
PYTHON_COMPAT=( python2_{6,7} ) or equivalent, and since python2_6
(and earlier) isn't in the supported implementations list, that leaves
just python2_7.  If you'd like, I can do up a list.

> Personally, I'd prefer to stick with my existing 
> PYTHON_SINGLE_TARGET. If a package doesn't like that, I can think 
> harder about whether or not I actually need the package.  My
> Docker images [1], for example, are single-Python implementations
> and I don't want to pull in another Python accidentally.

This change will not pull in extra python versions, it just changes
the python-single-r1 inheriting ebuilds so that they rely on the
values set in PYTHON_TARGETS for resolution, instead of
PYTHON_SINGLE_TARGET.

So the only way you would accidentally pull in a different python is
if you didn't set PYTHON_TARGETS, or set it to have multiple values.
PYTHON_SINGLE_TARGET is only for choosing which of the PYTHON_TARGETS
values should be used when a package can't multibuild.


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

iF4EAREIAAYFAlRRNIgACgkQ2ugaI38ACPDVLwD8DZpnfB6c6XsVbcNADycHS1K3
VjaOeFzVn2VghqHaaaABAKLDaaOPDj7YBZUEufJqtN2BdHkQKPub11vPnuWVN2eI
=I8M9
-----END PGP SIGNATURE-----

Re: [gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[Ian Stakenvicius]

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

On 29/10/14 02:42 PM, W. Trevor King wrote:
> On Wed, Oct 29, 2014 at 02:33:47PM -0400, Ian Stakenvicius wrote:
>> On 29/10/14 02:25 PM, W. Trevor King wrote:
>>> Personally, I'd prefer to stick with my existing 
>>> PYTHON_SINGLE_TARGET. If a package doesn't like that, I can
>>> think harder about whether or not I actually need the package.
>>> My Docker images [1], for example, are single-Python
>>> implementations and I don't want to pull in another Python
>>> accidentally.
>> 
>> This change will not pull in extra python versions, it just
>> changes the python-single-r1 inheriting ebuilds so that they rely
>> on the values set in PYTHON_TARGETS for resolution, instead of 
>> PYTHON_SINGLE_TARGET.
> 
> Ah, so it's “feel free to ignore my PYTHON_SINGLE_TARGET”, not
> “feel free to ignore my PYTHON_TARGETS.”


Correct.  Apologies for not making that clearer in my original post.


> ...  That works for me, since I don't care what version of Python a
> single-implementation package is installed with (as long as it's in
> my PYTHON_TARGETS and any dependers are satisfied).
> 

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

iF4EAREIAAYFAlRRNjwACgkQ2ugaI38ACPAtsAD+LvqjOPXrv1T9IyP3EqTeuqZX
qO366NnqnlOwgq4wZ3MA/A9znOhCF95vC0DEhh/NtXlxgY16D6cB4Fg2VH4Qp/VN
=maFF
-----END PGP SIGNATURE-----

Re: [gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

Dnia 2014-10-29, o godz. 14:39:52
Ian Stakenvicius <axs@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 29/10/14 02:31 PM, Michał Górny wrote:
> > 
> > This is ugly.
> > 
> > I was rather thinking of making all eclasses put +impl in IUSE when
> > only one implementation is supported.
> > 
> 
> ...how would that work?  PYTHON_SINGLE_TARGET as set in make.conf
> overrides the +impl in IUSE.

Does it?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[Mike Gilbert]

On Wed, Oct 29, 2014 at 4:09 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2014-10-29, o godz. 14:39:52
> Ian Stakenvicius <axs@gentoo.org> napisał(a):
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 29/10/14 02:31 PM, Michał Górny wrote:
>> >
>> > This is ugly.
>> >
>> > I was rather thinking of making all eclasses put +impl in IUSE when
>> > only one implementation is supported.
>> >
>>
>> ...how would that work?  PYTHON_SINGLE_TARGET as set in make.conf
>> overrides the +impl in IUSE.
>
> Does it?
>

Yes, it does.

Personally, I would prefer to remove PYTHON_SINGLE_TARGET from
profiles and have all python-single-r1 ebuilds set a +impl in IUSE.
Just need a reasonable algorithm for determining what that impl should
be.

Re: [gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

Dnia 2014-10-29, o godz. 16:21:20
Mike Gilbert <floppym@gentoo.org> napisał(a):

> On Wed, Oct 29, 2014 at 4:09 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > Dnia 2014-10-29, o godz. 14:39:52
> > Ian Stakenvicius <axs@gentoo.org> napisał(a):
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA256
> >>
> >> On 29/10/14 02:31 PM, Michał Górny wrote:
> >> >
> >> > This is ugly.
> >> >
> >> > I was rather thinking of making all eclasses put +impl in IUSE when
> >> > only one implementation is supported.
> >> >
> >>
> >> ...how would that work?  PYTHON_SINGLE_TARGET as set in make.conf
> >> overrides the +impl in IUSE.
> >
> > Does it?
> >
> 
> Yes, it does.
> 
> Personally, I would prefer to remove PYTHON_SINGLE_TARGET from
> profiles and have all python-single-r1 ebuilds set a +impl in IUSE.
> Just need a reasonable algorithm for determining what that impl should
> be.

Indeed it does. However, profiles don't seem to affect +flag for me.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[Ian Stakenvicius]

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

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

After discussion and review by mgorny, and significantly more testing,
here's an updated version of the previous patch.

To reiterate, this patch changes python-single-r1 so that if there is
only one supported Python implementation that can satisfy the ebuild,
then PYTHON_SINGLE_TARGET is ignored, and the ebuild is bound by the
value(s) set in PYTHON_TARGETS instead.


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

iF4EAREIAAYFAlRSj60ACgkQ2ugaI38ACPDIQwEAkcwuJi8sKy7ibCP8jlEbs2yp
1MLvsTwK2EUFeA9YvvkA/3xS38o0OAlZ0M9+ciZHDDGaSvsS/K85DWdDI88XSFJ/
=wlEW
-----END PGP SIGNATURE-----

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 10372 bytes --]

Index: python-single-r1.eclass
===================================================================
RCS file: /var/cvsroot/gentoo-x86/eclass/python-single-r1.eclass,v
retrieving revision 1.26
diff -u -B -U50 -w -r1.26 python-single-r1.eclass
--- python-single-r1.eclass	26 May 2014 16:13:35 -0000	1.26
+++ python-single-r1.eclass	30 Oct 2014 19:20:10 -0000
@@ -1,69 +1,70 @@
 # Copyright 1999-2014 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/eclass/python-single-r1.eclass,v 1.26 2014/05/26 16:13:35 mgorny Exp $
 
 # @ECLASS: python-single-r1
 # @MAINTAINER:
 # Python team <python@gentoo.org>
 # @AUTHOR:
 # Author: Michał Górny <mgorny@gentoo.org>
 # Based on work of: Krzysztof Pawlik <nelchael@gentoo.org>
 # @BLURB: An eclass for Python packages not installed for multiple implementations.
 # @DESCRIPTION:
 # An extension of the python-r1 eclass suite for packages which
 # don't support being installed for multiple Python implementations.
 # This mostly includes tools embedding Python.
 #
 # This eclass extends the IUSE and REQUIRED_USE set by python-r1
-# to request correct PYTHON_SINGLE_TARGET. It also replaces
-# PYTHON_USEDEP and PYTHON_DEPS with a more suitable form.
+# to request the PYTHON_SINGLE_TARGET when the inheriting ebuild
+# can be supported by more than one Python implementation. It also
+# replaces PYTHON_USEDEP and PYTHON_DEPS with a more suitable form.
 #
 # Please note that packages support multiple Python implementations
 # (using python-r1 eclass) can not depend on packages not supporting
 # them (using this eclass).
 #
 # Please note that python-single-r1 will always inherit python-utils-r1
 # as well. Thus, all the functions defined there can be used
 # in the packages using python-single-r1, and there is no need ever
 # to inherit both.
 #
 # For more information, please see the python-r1 Developer's Guide:
 # http://www.gentoo.org/proj/en/Python/python-r1/dev-guide.xml
 
 case "${EAPI:-0}" in
 	0|1|2|3)
 		die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
 		;;
 	4|5)
 		# EAPI=4 is required for USE default deps on USE_EXPAND flags
 		;;
 	*)
 		die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
 		;;
 esac
 
 if [[ ! ${_PYTHON_SINGLE_R1} ]]; then
 
 if [[ ${_PYTHON_R1} ]]; then
 	die 'python-single-r1.eclass can not be used with python-r1.eclass.'
 elif [[ ${_PYTHON_ANY_R1} ]]; then
 	die 'python-single-r1.eclass can not be used with python-any-r1.eclass.'
 fi
 
 inherit python-utils-r1
 
 fi
 
 EXPORT_FUNCTIONS pkg_setup
 
 if [[ ! ${_PYTHON_SINGLE_R1} ]]; then
 
 # @ECLASS-VARIABLE: PYTHON_COMPAT
 # @REQUIRED
 # @DESCRIPTION:
 # This variable contains a list of Python implementations the package
 # supports. It must be set before the `inherit' call. It has to be
 # an array.
 #
 # Example:
 # @CODE
@@ -89,177 +90,212 @@
 # @CODE
 #
 # It will cause the Python dependencies to look like:
 # @CODE
 # python_single_target_pythonX_Y? ( dev-lang/python:X.Y[gdbm,ncurses(-)?] )
 # @CODE
 
 # @ECLASS-VARIABLE: PYTHON_DEPS
 # @DESCRIPTION:
 # This is an eclass-generated Python dependency string for all
 # implementations listed in PYTHON_COMPAT.
 #
 # The dependency string is conditional on PYTHON_SINGLE_TARGET.
 #
 # Example use:
 # @CODE
 # RDEPEND="${PYTHON_DEPS}
 #	dev-foo/mydep"
 # DEPEND="${RDEPEND}"
 # @CODE
 #
 # Example value:
 # @CODE
 # dev-lang/python-exec:=
 # python_single_target_python2_6? ( dev-lang/python:2.6[gdbm] )
 # python_single_target_python2_7? ( dev-lang/python:2.7[gdbm] )
 # @CODE
 
 # @ECLASS-VARIABLE: PYTHON_USEDEP
 # @DESCRIPTION:
 # This is an eclass-generated USE-dependency string which can be used to
 # depend on another Python package being built for the same Python
 # implementations.
 #
 # The generate USE-flag list is compatible with packages using python-r1,
 # python-single-r1 and python-distutils-ng eclasses. It must not be used
 # on packages using python.eclass.
 #
 # Example use:
 # @CODE
 # RDEPEND="dev-python/foo[${PYTHON_USEDEP}]"
 # @CODE
 #
 # Example value:
 # @CODE
 # python_targets_python2_7(-)?,python_single_target_python2_7(+)?
 # @CODE
 
 # @ECLASS-VARIABLE: PYTHON_REQUIRED_USE
 # @DESCRIPTION:
-# This is an eclass-generated required-use expression which ensures the following:
+# This is an eclass-generated required-use expression which ensures the following
+# when more than one python implementation is possible:
 # 1. Exactly one PYTHON_SINGLE_TARGET value has been enabled.
 # 2. The selected PYTHON_SINGLE_TARGET value is enabled in PYTHON_TARGETS.
 #
 # This expression should be utilized in an ebuild by including it in
 # REQUIRED_USE, optionally behind a use flag.
 #
 # Example use:
 # @CODE
 # REQUIRED_USE="python? ( ${PYTHON_REQUIRED_USE} )"
 # @CODE
 #
 # Example value:
 # @CODE
 # python_single_target_python2_6? ( python_targets_python2_6 )
 # python_single_target_python2_7? ( python_targets_python2_7 )
 # ^^ ( python_single_target_python2_6 python_single_target_python2_7 )
 # @CODE
 
 _python_single_set_globals() {
 	local impls=()
 
 	PYTHON_DEPS=
 	local i PYTHON_PKG_DEP
 	for i in "${PYTHON_COMPAT[@]}"; do
 		_python_impl_supported "${i}" || continue
-
-		# The chosen targets need to be in PYTHON_TARGETS as well.
-		# This is in order to enforce correct dependencies on packages
-		# supporting multiple implementations.
-		PYTHON_REQUIRED_USE+=" python_single_target_${i}? ( python_targets_${i} )"
-
-		python_export "${i}" PYTHON_PKG_DEP
-		PYTHON_DEPS+="python_single_target_${i}? ( ${PYTHON_PKG_DEP} ) "
-
 		impls+=( "${i}" )
 	done
 
 	if [[ ${#impls[@]} -eq 0 ]]; then
 		die "No supported implementation in PYTHON_COMPAT."
 	fi
 
 	local flags_mt=( "${impls[@]/#/python_targets_}" )
 	local flags=( "${impls[@]/#/python_single_target_}" )
 
 	local optflags=${flags_mt[@]/%/(-)?}
+
+	IUSE="${flags_mt[*]}"
+
+	if [[ ${#impls[@]} -eq 1 ]]; then
+		# There is only one supported implementation; set IUSE and other
+		# variables without PYTHON_SINGLE_TARGET.
+		PYTHON_REQUIRED_USE="${flags_mt[*]}"
+		python_export "${impls[0]}" PYTHON_PKG_DEP
+		PYTHON_DEPS="${PYTHON_PKG_DEP} "
+		# Force on the python_single_target_* flag for this impl, so
+		# that any dependencies that inherit python-single-r1 and
+		# happen to have multiple implementations will still need
+		# to bound by the implementation used by this package.
+		optflags+=,${flags[0]/%/(+)}
+	else
+		# Multiple supported implementations; honor PYTHON_SINGLE_TARGET.
+		IUSE+=" ${flags[*]}"
+		PYTHON_REQUIRED_USE="^^ ( ${flags[*]} )"
+		# Ensure deps honor the same python_single_target_* flag as is set
+		# on this package.
 	optflags+=,${flags[@]/%/(+)?}
 
-	IUSE="${flags_mt[*]} ${flags[*]}"
-	PYTHON_REQUIRED_USE+=" ^^ ( ${flags[*]} )"
+		for i in "${impls[@]}"; do
+			# The chosen targets need to be in PYTHON_TARGETS as well.
+			# This is in order to enforce correct dependencies on packages
+			# supporting multiple implementations.
+			PYTHON_REQUIRED_USE+=" python_single_target_${i}? ( python_targets_${i} )"
+
+			python_export "${i}" PYTHON_PKG_DEP
+			PYTHON_DEPS+="python_single_target_${i}? ( ${PYTHON_PKG_DEP} ) "
+		done
+	fi
 	PYTHON_USEDEP=${optflags// /,}
 
 	# 1) well, python-exec would suffice as an RDEP
 	# but no point in making this overcomplex, BDEP doesn't hurt anyone
 	# 2) python-exec should be built with all targets forced anyway
 	# but if new targets were added, we may need to force a rebuild
 	# 3) use whichever python-exec slot installed in EAPI 5. For EAPI 4,
 	# just fix :2 since := deps are not supported.
 	if [[ ${_PYTHON_WANT_PYTHON_EXEC2} == 0 ]]; then
 		PYTHON_DEPS+="dev-lang/python-exec:0[${PYTHON_USEDEP}]"
 	elif [[ ${EAPI} != 4 ]]; then
 		PYTHON_DEPS+="dev-lang/python-exec:=[${PYTHON_USEDEP}]"
 	else
 		PYTHON_DEPS+="dev-lang/python-exec:2[${PYTHON_USEDEP}]"
 	fi
 }
 _python_single_set_globals
 
 # @FUNCTION: python_setup
 # @DESCRIPTION:
 # Determine what the selected Python implementation is and set
 # the Python build environment up for it.
 python_setup() {
 	debug-print-function ${FUNCNAME} "${@}"
 
 	unset EPYTHON
 
-	local impl
-	for impl in "${_PYTHON_ALL_IMPLS[@]}"; do
-		if has "${impl}" "${PYTHON_COMPAT[@]}" \
-			&& use "python_single_target_${impl}"
-		then
+	local impl impls=()
+	for impl in "${PYTHON_COMPAT[@]}"; do
+		_python_impl_supported "${impl}" || continue
+		impls+=( "${impl}" )
+	done
+
+	if [[ ${#impls[@]} -eq 1 ]]; then
+		if use "python_targets_${impls[0]}"; then
+			# Only one supported implementation, enable it explicitly
+			python_export "${impls[0]}" EPYTHON PYTHON
+			python_wrapper_setup
+		fi
+	else
+		for impl in "${impls[@]}"; do
+			if use "python_single_target_${impl}"; then
 			if [[ ${EPYTHON} ]]; then
 				eerror "Your PYTHON_SINGLE_TARGET setting lists more than a single Python"
 				eerror "implementation. Please set it to just one value. If you need"
 				eerror "to override the value for a single package, please use package.env"
 				eerror "or an equivalent solution (man 5 portage)."
 				echo
 				die "More than one implementation in PYTHON_SINGLE_TARGET."
 			fi
 
 			if ! use "python_targets_${impl}"; then
 				eerror "The implementation chosen as PYTHON_SINGLE_TARGET must be added"
 				eerror "to PYTHON_TARGETS as well. This is in order to ensure that"
 				eerror "dependencies are satisfied correctly. We're sorry"
 				eerror "for the inconvenience."
 				echo
 				die "Build target (${impl}) not in PYTHON_TARGETS."
 			fi
 
 			python_export "${impl}" EPYTHON PYTHON
 			python_wrapper_setup
 		fi
 	done
+	fi
 
 	if [[ ! ${EPYTHON} ]]; then
 		eerror "No Python implementation selected for the build. Please set"
+		if [[ ${#impls[@]} -eq 1 ]]; then
+			eerror "the PYTHON_TARGETS variable in your make.conf to include one"
+		else
 		eerror "the PYTHON_SINGLE_TARGET variable in your make.conf to one"
+		fi
 		eerror "of the following values:"
 		eerror
-		eerror "${PYTHON_COMPAT[@]}"
+		eerror "${impls[@]}"
 		echo
-		die "No supported Python implementation in PYTHON_SINGLE_TARGET."
+		die "No supported Python implementation in PYTHON_SINGLE_TARGET/PYTHON_TARGETS."
 	fi
 }
 
 # @FUNCTION: python-single-r1_pkg_setup
 # @DESCRIPTION:
 # Runs python_setup.
 python-single-r1_pkg_setup() {
 	debug-print-function ${FUNCNAME} "${@}"
 
 	python_setup
 }
 
 _PYTHON_SINGLE_R1=1
 fi

Re: [gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

Dnia 2014-10-30, o godz. 15:21:17
Ian Stakenvicius <axs@gentoo.org> napisał(a):

> After discussion and review by mgorny, and significantly more testing,
> here's an updated version of the previous patch.
> 
> To reiterate, this patch changes python-single-r1 so that if there is
> only one supported Python implementation that can satisfy the ebuild,
> then PYTHON_SINGLE_TARGET is ignored, and the ebuild is bound by the
> value(s) set in PYTHON_TARGETS instead.

It is not ignored but not declared, which is good. Ignoring is bad :).

So I was pretty skeptic about this at first but after thinking it all
over a few times, I think it will work just fine. While it benefits
only the 'bad' kind of packages and adds some complexity, I believe
this is a worthwhile change.

Now that Python 2.6 is removed, there are many packages that support
only Python 2.7. For those packages, having two control variables is
pointless. We still need to keep PYTHON_TARGETS for USE dependency
matches against the package but we can safely remove
PYTHON_SINGLE_TARGET for it will be handled properly by (+) and (-)
defaults in the eclasses.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[Mike Gilbert]

On Thu, Oct 30, 2014 at 3:43 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2014-10-30, o godz. 15:21:17
> Ian Stakenvicius <axs@gentoo.org> napisał(a):
>
>> After discussion and review by mgorny, and significantly more testing,
>> here's an updated version of the previous patch.
>>
>> To reiterate, this patch changes python-single-r1 so that if there is
>> only one supported Python implementation that can satisfy the ebuild,
>> then PYTHON_SINGLE_TARGET is ignored, and the ebuild is bound by the
>> value(s) set in PYTHON_TARGETS instead.
>
> It is not ignored but not declared, which is good. Ignoring is bad :).
>
> So I was pretty skeptic about this at first but after thinking it all
> over a few times, I think it will work just fine. While it benefits
> only the 'bad' kind of packages and adds some complexity, I believe
> this is a worthwhile change.

I guess I'm still a little skeptical.

What is the advantage to making such a change to python-single-r1 as
opposed to just using python-r1 with a single implementation in
PYTHON_COMPAT?

Re: [gentoo-python] Reducing exceptionality cases for PYTHON_SINGLE_TARGET

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

Dnia 2014-10-30, o godz. 16:26:51
Mike Gilbert <floppym@gentoo.org> napisał(a):

> On Thu, Oct 30, 2014 at 3:43 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > Dnia 2014-10-30, o godz. 15:21:17
> > Ian Stakenvicius <axs@gentoo.org> napisał(a):
> >
> >> After discussion and review by mgorny, and significantly more testing,
> >> here's an updated version of the previous patch.
> >>
> >> To reiterate, this patch changes python-single-r1 so that if there is
> >> only one supported Python implementation that can satisfy the ebuild,
> >> then PYTHON_SINGLE_TARGET is ignored, and the ebuild is bound by the
> >> value(s) set in PYTHON_TARGETS instead.
> >
> > It is not ignored but not declared, which is good. Ignoring is bad :).
> >
> > So I was pretty skeptic about this at first but after thinking it all
> > over a few times, I think it will work just fine. While it benefits
> > only the 'bad' kind of packages and adds some complexity, I believe
> > this is a worthwhile change.
> 
> I guess I'm still a little skeptical.
> 
> What is the advantage to making such a change to python-single-r1 as
> opposed to just using python-r1 with a single implementation in
> PYTHON_COMPAT?

1. It's easier to use than python-r1,

2. It doesn't pretend you support multiple implementations. Someone
won't get a big zonk attempting to enable python3 support one day.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]