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 074DD1381F3 for ; Sun, 11 Nov 2012 07:39:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A452FE00AB; Sun, 11 Nov 2012 07:39:17 +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 031BCE00AB for ; Sun, 11 Nov 2012 07:39:16 +0000 (UTC) Received: from pomiocik.lan (87-205-67-82.adsl.inetia.pl [87.205.67.82]) (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 CF5A833D865; Sun, 11 Nov 2012 07:39:14 +0000 (UTC) Date: Sun, 11 Nov 2012 08:40:04 +0100 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: Ben de Groot Cc: gentoo-python , Gentoo Python Project Subject: Re: [gentoo-python] python-r1 <-> python.eclass package dependencies Message-ID: <20121111084004.48a7b644@pomiocik.lan> In-Reply-To: References: <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_/lCklPXEstk4XZ6r5cTkTh1U"; protocol="application/pgp-signature" X-Archives-Salt: 7f154560-e2f4-4b6f-9e03-0b0a8f2d7519 X-Archives-Hash: e7c42a69f25c96b0f7bdbfd5eb6aff32 --Sig_/lCklPXEstk4XZ6r5cTkTh1U Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 11 Nov 2012 14:29:20 +0800 Ben de Groot wrote: > On 11 November 2012 00:43, Micha=C5=82 G=C3=B3rny wro= te: >=20 > > 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 her= e). > > > > > > 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? > I'm sorry if I missed something, but I don't see why USE_PYTHON should be > considered not public. That has been the only mechanism until now (in > combination with package.mask) to get a consistent system without redunda= nt > multiple python versions. Well, the most important reason is that I don't think USE_PYTHON is pretty much documented *anywhere*. > I think it is easiest to tell users to set USE_PYTHON as well, until > python.eclass is finally phased out. Yes, that's what the warning would say. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/lCklPXEstk4XZ6r5cTkTh1U Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iJsEAQEIAAYFAlCfVlwACgkQfXuS5UK5QB3vmgP45oiQWHPW2W3TyOtEUpSOICgJ jdM0K8VIYzdU8ldu/mw9yLCF7dm3C1mdIDuHgKFKO6RZsbvA25VZt8ZKi9Npy7wY il/3eByleD9SwZ0XPoNUzWEiVIIt7ZfeIjMRu06qi8/+b8xi1KP9geKc07JSN3jR nLpJ0HeSE9CvV0IXug== =Gk3h -----END PGP SIGNATURE----- --Sig_/lCklPXEstk4XZ6r5cTkTh1U--