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 32B31138334 for ; Sun, 24 Nov 2019 13:21:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7A6EEE0830; Sun, 24 Nov 2019 13:21:12 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 19E0AE077F for ; Sun, 24 Nov 2019 13:21:12 +0000 (UTC) Received: from enyo.lan (62-11-73-76.dialup.tiscali.it [62.11.73.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 2C17A34D2BC; Sun, 24 Nov 2019 13:21:09 +0000 (UTC) Subject: [gentoo-dev] Re: [RFC] Perspectives on improving (dis-hacking) python-single-r1 To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= , gentoo-dev Cc: python References: <24b13fdee7d49d5575c42984bf773eef3a869615.camel@gentoo.org> From: Luca Barbato Message-ID: <63130c40-3681-fb57-d7ce-7faa21237f1a@gentoo.org> Date: Sun, 24 Nov 2019 14:21:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Thunderbird/71.0 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 In-Reply-To: <24b13fdee7d49d5575c42984bf773eef3a869615.camel@gentoo.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Archives-Salt: c0380a0d-e158-40e1-a774-8c0722971e24 X-Archives-Hash: a57150b6afad382e3612803d4e6b3e04 On 23/11/2019 16:48, Michał Górny wrote: > Hello, > > Some aspects of the current design of python-single-r1 are gross hack. > I'd like to discuss potential alternatives to them. > > > Preamble > ======== > 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 > ============== > 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 > ================================== > The first alternative I'd like to explore is removing > PYTHON_SINGLE_TARGET flags. Why were they added in the first place? > 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 > ================================= > 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. > 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="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 > ============= > So, WDYT? Do you think this approach is worthwhile? Do you see other > options? > > The new dependency API proposal looks nicer to me. lu