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 3285A1381F3 for ; Sat, 10 Nov 2012 16:42:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5AB3521C010; Sat, 10 Nov 2012 16:42:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id ABBF721C010 for ; Sat, 10 Nov 2012 16:42:23 +0000 (UTC) Received: from pomiocik.lan (77-254-166-182.adsl.inetia.pl [77.254.166.182]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id B15B633D7FD; Sat, 10 Nov 2012 16:42:21 +0000 (UTC) Date: Sat, 10 Nov 2012 17:43:22 +0100 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-python@lists.gentoo.org Cc: python@gentoo.org Subject: [gentoo-python] python-r1 <-> python.eclass package dependencies Message-ID: <20121110174322.656f1d67@pomiocik.lan> Organization: Gentoo X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; 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-SHA256; boundary="Sig_/9gy.kKMA9nC7B1qCHMiA254"; protocol="application/pgp-signature" X-Archives-Salt: c44ca3ca-edfd-4f0a-8071-94b5c2c1da94 X-Archives-Hash: bdcb25ae1b96689c0786631eab0bf4f1 --Sig_/9gy.kKMA9nC7B1qCHMiA254 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 !=3D 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? --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/9gy.kKMA9nC7B1qCHMiA254 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iJwEAQEIAAYFAlCehC4ACgkQfXuS5UK5QB0XPQP/Qq8+g/U0l06DkO87p4aoKe7E wVY8bJ7+EUgnSINFUHuzpvvhtrnjafUXKIy/tT3uNDAgV2fc1xQ0CWSYd5u9noL2 18B1zSVTmeRFCfbFPZKnLWiA51tkfRMmdGp5uJVvT693d6Y+WYlzHTdxfA9ppiOu 7LRuSnI3KPE883d8Hx4= =rIrD -----END PGP SIGNATURE----- --Sig_/9gy.kKMA9nC7B1qCHMiA254--