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 285661389E2 for ; Fri, 28 Nov 2014 22:59:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A19A0E0897; Fri, 28 Nov 2014 22:59: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 2A18DE0897 for ; Fri, 28 Nov 2014 22:59:42 +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 5F1C93404EA; Fri, 28 Nov 2014 22:59:40 +0000 (UTC) Date: Fri, 28 Nov 2014 23:59:27 +0100 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: gentoo-python@lists.gentoo.org Cc: python@gentoo.org Subject: [gentoo-python] The future of PYTHON_SINGLE_TARGET Message-ID: <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_/tQehs8jz_PSBESYkuDBrcwD"; protocol="application/pgp-signature" X-Archives-Salt: f0041739-0b66-4820-89a3-f89c51bba4b0 X-Archives-Hash: 9121fee09ced169c2b316039df8d3d14 --Sig_/tQehs8jz_PSBESYkuDBrcwD Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Friends! The current state of python-single-r1 bothered me a lot lately, and while _AxS_ did some neat improvements to the eclass, it's still far from perfect solution to our users. The PYTHON_SINGLE_TARGET flags were added to make it easier to handle single-impl packages that support both Python 2 & Python 3 which we enable both in our profiles. It serves that purpose well -- however, it isn't that good for single-impl packages that don't support the most common choice of implementations. In particular, it has two major issues: 1. We have no sane, clear and universal way of providing users with sensible defaults. It's always one trade-off over another. 2. Matching USE dependencies against multi-impl packages introduces a second set of USE flags (PYTHON_TARGETS) that are semi-virtual. Sadly, they introduce confusion and cause issues. 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. 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, 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. To be honest, I don't see a good way out of this. Possible bad ways: I. disable PYTHON_SINGLE_TARGET and use PYTHON_REQUIRED_USE=3D"^^ ..." when python2_7 is not in PYTHON_COMPAT. In other words, add another workaround that gets things rolling with the default profile setup. II. Remove PYTHON_SINGLE_TARGET completely and use PYTHON_REQUIRED_USE=3D"^^ ...". Option (1) is 'uglier' since it introduces another special case and adds to the complexity. However, it supposedly impacts the lowest number of users -- the default profile settings should pass, and only people enabling more implementations would have to disable the flags. Option (2) is cleaner but it imposes a major shock to our users. It specifically involves manipulating USE flags on a lot of packages even with the default profiles. Both options come with another major drawback -- exactly-one-if deps force manipulating the flags. Once manipulation is done, it may make Python upgrades much harder -- esp. if portage would end up enabling older impls via p.use. Of course, this wouldn't be a problem if users only added -flags to disable the old implementations. Then the issue will reapply when a new implementation is enabled globally, making the effective of 2 enabled implementations. So, what are your thoughts? What are your solutions? --=20 Best regards, Micha=B3 G=F3rny --Sig_/tQehs8jz_PSBESYkuDBrcwD Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUeP5UXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOBbMQAKfO2+o+SoXnQwPbDpjL9ngu v8/U3Pc9it+VNIbCW7KLbtVnoYVimhGj53UNslKGp4nie1nbKc04VEJHCikdBuPo lOVbK7FbqknIGWCwk3AezZ9qGK3erxwYN0nKQkYMr6yMQI6qcnQEqWIr3j9ZaxGM rt2imoxn9RwkYbN8l6E2hd1hhilXnoifdEAgVlwNCOQ+sKPGO1abweqmQn4dYaT6 GHixMFQzfTC/L3W7ot5DtH9H5F8PGGTBvQAzuKquvZClfD9XWhOWssxAl84nPCvY Rc92YrmZbQvt7cV1ajF6d+yMmqrCi5o9IUt4GUuW6mu0g8IUKxsfWUmN/1tizb8p RC+VnVadwABYiYIvsEFlSr0t7hTVLTBtzWsIQJKXtE9t6frmjzWZgpt2ruIYzaxz /djvn/fkHjaEkTtJ36mjvvc976HwWzz7A0nzCX3aX8Pel04nBNpCcRLrDgw2JCN9 GOjNgIJ7y1VMtUYSvid9HB78c7nY6cBQqVC99Kc3tGy1E+8k/6AnW0SccyAyBW1q M65K/m19L5BuzyKutdO9YsqH6D+0/Pern6/+SaLN+fiUtOvks7thNtTfIAbsmBfJ TRoP1SMzkzIQjPSjuYi0lxhEtOsFpLh3NzFuAIP7e5S3hBreblhhRv1bssrHAElX HRksqw0812hUDb8CpRuN =JZbq -----END PGP SIGNATURE----- --Sig_/tQehs8jz_PSBESYkuDBrcwD--