From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 0E271138334 for ; Sat, 23 Nov 2019 15:48:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8B50DE07FA; Sat, 23 Nov 2019 15:48:09 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 39FE2E077F for ; Sat, 23 Nov 2019 15:48:09 +0000 (UTC) Received: from pomiot (c134-66.icpnet.pl [85.221.134.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id A272334D25C; Sat, 23 Nov 2019 15:48:07 +0000 (UTC) Message-ID: <24b13fdee7d49d5575c42984bf773eef3a869615.camel@gentoo.org> Subject: [gentoo-dev] [RFC] Perspectives on improving (dis-hacking) python-single-r1 From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev Cc: python Date: Sat, 23 Nov 2019 16:48:02 +0100 Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-N1iqZM0ad8A3MEbm+W9e" User-Agent: Evolution 3.32.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: a9133313-1b5d-4df1-bd46-0f3cf0b86b73 X-Archives-Hash: cf57747fb015ae1128198cfebefc6b38 --=-N1iqZM0ad8A3MEbm+W9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Some aspects of the current design of python-single-r1 are gross hack.=20 I'd like to discuss potential alternatives to them. Preamble =3D=3D=3D=3D=3D=3D=3D=3D For the purpose of this mail, let's establish two terms. 'Single' will refer to packages allowing the user to select 1 out of N supported Python implementations. This generally means programs linking to libpython, foreign build systems and end-user apps where installing multiple copies of the code makes no sense. Those are the packages using python-single-r1. 'Multi' will refer to packages allowing the user to select M out of N supported Python implementations. This generally means ebuilds for Python packages (modules, extensions). Those are the packages using python-r1 (usually via distutils-r1). 'Single' packages can PYTHON_USEDEP-end either on other 'single' or on 'multi' packages. However, 'multi' packages can only PYTHON_USEDEP-end on other 'multi' packages (because 'single' wouldn't ever be able to satisfy >1 impl). Current status =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Currently, 'single' packages use two sets of USE flags: PYTHON_TARGETS and PYTHON_SINGLE_TARGET. The latter is used to select the implementation used, and the former is used only for technical reasons. Selected PST is required to be also enabled in PT. All dependencies enforce both PST and PT match. The PYTHON_USEDEP is generally a giant hack that's meant to work both for depending on 'single' and 'multi' packages. I'm not convinced this was the best choice anymore. In single-to-single deps, PYTHON_USEDEP enforces both PST and PT flags to match. This means that if two packages have matching PST but for some reason were built with different PT, users end up having to switch PT and rebuild the package without any real change. In single-to-multi deps, PYTHON_USEDEP enforces PT flags. For this reason, we need to enforce that selected PST is always present in PT, and users always have to put both flags in package.use. There's also a gross hack in PYTHON_USEDEP in 'multi' packages that means to prevent multi-to-single deps. However, the dep mismatch it causes is not very readable. Alternative 1: PYTHON_TARGETS only =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D The first alternative I'd like to explore is removing PYTHON_SINGLE_TARGET flags. Why were they added in the first place?=20 The primary goal was to be able to set PT to 2.7+3.x without requiring people to adjust flags for every 'single' package out there. Plus, it turned out very convenient for Python team members who want to enable all PT but obviously can't do the same for PST. Originally I brought this proposal in context of automated REQUIRED_USE conflict resolution. However, that was rejected by the Council. Still, it may start making sense again in the near future when we start removing py2.7 and pypy2.7 support. If we can limit PT to one implementation, and handle the remaining packages via IUSE defaults and package.use, this may just work. The inconvenience to people enabling multiple PT will remain though. Alternative 2: new dependency API =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D If PST is going to stay, we may look into removing PT from 'single' packages instead. The idea is to provide new method of generating cross-package deps that doesn't require fake flags. PYTHON_USEDEP would continue working through a transitional period.=20 When it's entirely gone, we can remove PYTHON_TARGETS from 'single' packages. Single-to-single deps would switch to PYTHON_SINGLE_USEDEP, that only enforces PST and disregards PT entirely. Single-to-multi deps would have to use a new generator function, $(python_gen_multi_dep ...) that would create appropriate USE-mapping from PST to PT. Example ebuild would have: RDEPEND=3D"app-foo/singlepkg[${PYTHON_SINGLE_USEDEP}] $(python_gen_multi_dep ' dev-python/foo[${PYTHON_USEDEP}] dev-python/bar[${PYTHON_USEDEP}] ')" This will generate something like: pst_python2_7? ( dev-python/foo[pt_python2_7(-)] dev-python/bar[pt_python2_7(-)] ) pst_python3_7? ( dev-python/foo[pt_python3_7(-)] dev-python/bar[pt_python3_7(-)] ) Your opinions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D So, WDYT? Do you think this approach is worthwhile? Do you see other options? --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-N1iqZM0ad8A3MEbm+W9e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAl3ZVLNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM3 NkE4NDUwOTQwOThEMjhDQzhCMjZDNTYzOUFEQUUyMzI5RTI0MEUACgkQY5ra4jKe JA7PfggAjLXcBskC5dhRksuW6jxvz4Xm2XTdQN+JRPO+SHIbRfSW8SM3QdkF69CQ fSbjvRnNWhMYjTtq8lkvsgw2jnLicnzgYxLRg+fHxjSDvJdWaL0XsuLd5fznUtx7 H8slqvyW3CyHJMwLtvVPh8BEohp1Fxd4k9FC2nHrww7ZeY5CKhTUSY0FB4Ag68Rl ywoUq5HGubHug+NLnMKSTZgAa2QsxnjGLwuCu7kYV3YTr4hH/lhmm0vFzpgJmvLg mv1qoTsb/6PgnkCBF+n3aOciEnrvDVzrl0JzoS5VFqjC6o/7mo/wfRu9pWhvORuL J6tjSZSrKlMBObeyIaxhMbJEeryS5A== =0YT1 -----END PGP SIGNATURE----- --=-N1iqZM0ad8A3MEbm+W9e--