From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id EA2A21389E2 for ; Sun, 30 Nov 2014 20:50:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7BBE4E0852; Sun, 30 Nov 2014 20:50:42 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F3F43E0852 for ; Sun, 30 Nov 2014 20:50:41 +0000 (UTC) Received: from pomiot.lan (mgorny-1-pt.tunnel.tserv28.waw1.ipv6.he.net [IPv6:2001:470:70:353::2]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 070463402BF; Sun, 30 Nov 2014 20:50:39 +0000 (UTC) Date: Sun, 30 Nov 2014 21:50:31 +0100 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: Mike Gilbert Cc: gentoo-python , Gentoo Python Project Subject: Re: [gentoo-python] Re: The future of PYTHON_SINGLE_TARGET Message-ID: <20141130215031.2b183cdf@pomiot.lan> In-Reply-To: References: <20141128235927.771a6e8b@pomiot.lan> Organization: Gentoo X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Discussions centering around the Python ecosystem in Gentoo Linux X-BeenThere: gentoo-python@gentoo.org X-BeenThere: gentoo-python@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/6LrIlWoNNMjVH5zS+5QcpXt"; protocol="application/pgp-signature" X-Archives-Salt: 4daa521c-7111-42bd-96a3-8d30dba30bdf X-Archives-Hash: 94096113646e9c19cbfe2f354a77f919 --Sig_/6LrIlWoNNMjVH5zS+5QcpXt Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-11-30, o godz. 13:12:18 Mike Gilbert napisa=B3(a): > On Fri, Nov 28, 2014 at 5:59 PM, Micha=B3 G=F3rny wro= te: > > 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. > > >=20 > I'm thinking we need to move the default PYTHON_SINGLE_TARGET setting > from profiles to IUSE defaults computed in the eclass. >=20 > What are the problems associated with that? Well, one issue I see is that it means we will have a 'moving' default. That is, different packages will have different (non-matching) defaults depending on supported implementations. Worse than that, adding a new implementation will change the default in one package which may conflict with its dependencies. Please consider the following example. We have two packages, AA and AB. Both are python-single-r1 and in version 1 both support 3.2+3.3, with 3.3 being the IUSE default. AB depends on AA[${PYTHON_USEDEP}]. Now, A-2 gets 3.4 support and 3.4 becomes the IUSE default. Now emerge -1vDtuN ab gives: emerge: there are no ebuilds built with USE flags to satisfy "dev-python/aa[python_targets_python3_3(-),python_single_target_python3_3(+= )]". !!! One of the following packages is required to complete your request: - dev-python/aa-2::mgorny (Change USE: +python_single_target_python3_3, this change violates use flag constraints defined by dev-python/aa-2: 'exactly-one-of ( python_single_target_python3_2 python_single_target_python3_3 python_single_target_python3_4 ) python_single_target_python3_2? ( python_targets_python3_2 ) python_single_target_python3_3? ( python_targets_python3_3 ) python_single_target_python3_4? ( python_targets_python3_4 )') (dependency required by "dev-python/ab-1::mgorny" [installed]) (dependency required by "ab" [argument]) This happens both when PST USE-deps are '?' and '=3D'. Now, assuming that user actually adds 3.3, he gets regular REQUIRED_USE conflict. He can solve it by removing 3.4 *explicitly*. Now he can upgrade. Note that PYTHON_TARGETS has 3.3+3.4 now (see issue below). Now good news, everyone! AB just gained 3.4 support, and therefore switched default again. Now portage at least suggests the right thing to do: The following USE changes are necessary to proceed: (see "package.use" in the portage(5) man page for more details) # required by dev-python/ab-2::mgorny # required by ab (argument) >=3Ddev-python/aa-2 python_single_target_python3_4 -python_single_target_py= thon3_3 This is good so far. Now, let's imagine we have three packages -- AA, AB and AC. AC also depends on AA and supports 3.2+3.3. This means that once AB and AA again 3.4 support, Portage ends up having a real conflict: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-python/aa:0 (dev-python/aa-2:0/0::mgorny, installed) pulled in by dev-python/aa[python_targets_python3_3(-),-python_single_target_python3= _2(+),python_single_target_python3_3(+)] required by (dev-python/ac-1:0/0::mgorny, installed)=20 (dev-python/aa-2:0/0::mgorny, ebuild scheduled for merge) pulled in by dev-python/aa[python_targets_python3_2(-)?,python_targets_python3_3(-)?= ,python_targets_python3_4(-)?,python_single_target_python3_2(+)=3D,python_s= ingle_target_python3_3(+)=3D,python_single_target_python3_4(+)=3D] required by (dev-python/ab-2:0/0::mgorny, ebuild scheduled for merge) Not good at all. Portage still suggests enabling 3.4 on AA but that only makes things worse. If you force 3.3 on AB, it lets you continue. Once AC gets 3.4, Portage says to switch AA to 3.4. Once you do that, it tells you to switch it to 3.3 (because of AB). Guess what it tells you to do next :). > > 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, >=20 > That would seem to be the exception rather than the norm. This would > only happen if we somehow defaulted PYTHON_SINGLE_TARGET to something > that is not in PYTHON_TARGETS by default. How would that ever happen? Forget about this. I guess we can enable the same PYTHON_TARGET and PYTHON_SINGLE_TARGET via IUSE defaults. > > 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. >=20 > I don't understand this part. Can you please explain it? Maybe an example? gedit and libpeas, with gedit depending on libpeas. libpeas supports one version of Python 2 and one of Python 3, and gedit just one in general: libpeas is REQUIRED_USE=3D?? ( 2.* ) ?? ( 3.* ) gedit is REQUIRED_USE=3D^^ ( 3.* ) So libpeas needs python-r1 with specific REQUIRED_USE. gedit would be a candidate for python-single-r1 but... p-s-r1 enforces ^^ only on PYTHON_SINGLE_TARGET. So I end up with something like: PYTHON_TARGETS=3D"3.3 3.4" PYTHON_SINGLE_TARGET=3D"3.4" and this enforces dependency on libpeas[3.3,3.4] which contradicts its REQUIRED_USE. So we need also REQUIRED_USE=3D^^ ( 3.* ). But basically, the whole mess with the second variable doesn't really help here. --=20 Best regards, Micha=B3 G=F3rny --Sig_/6LrIlWoNNMjVH5zS+5QcpXt Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUe4MXXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOL8MP/Axl1JeIyW0R6yMrfXvcUrnY pkBs6IrSsr4Te2gl16n1D+ceheR1+U2wJ3qOG9bS9ubOoTYgPVoFsamWixjxTTTY f/rTbWMAVlb+LyCyFse/U6bFrbp+Jxz7tDQXFi5i5ZoSO6JphTbiuSLUOlqTyM0k 6GkUbqBo8sXjPmU5N/PH3uJmmO6URVsmnGthQba+uOqzfYG2NjIqzBJSJQ5te+s7 tqdxKhBmJspohnEdOP1qZLh03nlC+WH9LpkF1pU2SBJBg2och66lcTU6o0/DTheJ WJu3wHLmDsaeFiP6bLWoQRlq3FzUkgr9uWMlKsRQNXHV/2tq3hFiUbWFHpwl0JYG EwqzoHLXdN+dtmqh7Jokw6IY/WgZXaG0bSJdmyNOB758/tJmw0zFlFLMnoYR3Kii d1ASyDKmbxi53OHHPsz/jpcwzbluQZFpvplJvRcKLowBGmQAWEJfXybK6KVyGF0N 30RuYwT6x7av1oe1nvFb2qGyOcrWz0myPa71baXYWdXO3g/upDsriQY7B6Pcyv5w RIEII5mVu58+p3BqvZKTZMn9MTQfYMTRw+rDCsAwj32qGsQnlosnJOt6/I6tnzpV OQIHVRvYUcI9NwTjWkHcH0wzBffN+9wCYIQm0KLWKlAXwEJufl6XcTxPVgc2R/AU Dkv9i9WqQQngdyOxQ1d8 =2j3K -----END PGP SIGNATURE----- --Sig_/6LrIlWoNNMjVH5zS+5QcpXt--