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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9668C158046 for ; Mon, 14 Oct 2024 00:43:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F187BE0837; Mon, 14 Oct 2024 00:43:44 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BB7B1E0824 for ; Mon, 14 Oct 2024 00:43:44 +0000 (UTC) From: Sam James To: =?utf-8?B?TWljaGHFgiBHw7Nybnk=?= Cc: gentoo-dev@lists.gentoo.org, python@gentoo.org Subject: Re: [gentoo-dev] [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14 In-Reply-To: (=?utf-8?Q?=22Micha=C5=82_G=C3=B3rny=22's?= message of "Sat, 12 Oct 2024 10:12:56 +0200") Organization: Gentoo References: Date: Mon, 14 Oct 2024 01:43:40 +0100 Message-ID: <87o73nldj7.fsf@gentoo.org> 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: fb92db80-c2ce-44db-931e-2cff00ba52c0 X-Archives-Hash: ae2b92c411e51684e650a93246fd5d25 Micha=C5=82 G=C3=B3rny writes: > Hello, > > Historically, all versions of CPython were slotted in a single package, > i.e.: > > dev-lang/python:3.N > I feel like this whole thing happened so fast I didn't have a chance to comment properly. I understand you've retracted it but I'd like to add some context and background and so on for future reference anyway. > This approach has been causing a major annoyance for users -- due to > Portage "greedy" upgrade behavior, any time a new Python version was > keyworded, Portage insisted on installing it, even though user's > selected targets did not request the specific version. The potentially > worst consequence of that would be random user scripts stopping to work, > as they suddenly start using new Python, while all their dependencies > are still installed per PYTHON_TARGETS. > This is bug #702806 which happens with python-any-r1 which has an any-of dependency on dev-lang/python. That's why we don't see it with e.g. Qt. It's a bit annoying but not terrible. > Upstream has recently added freethreading support to CPython. Since > this support is not ABI compatible with the regular build, we need to > introduce a separate target for it, and to package it separately. > In the planned patchset, I've already put it as a separate package (dev- > lang/python-freethreading), because otherwise Portage would insist > on upgrading to it! > It wouldn't! See above. It would, however, if we made it eligible for python-any-r1, but to be honest, I think we should exclude the freethreaded build from that. It's all risk (and/or downsides) with no real gain, as I don't expect a whole-freethreaded system is going to be possible any time soon anyway. > However, I think the cleanest way forward would be to stop slotting > CPython like this, and instead have a separate package for each version, > just like the vast majority of distributions do, i.e.: > > dev-lang/python3_N > As others have noted, such a proposal needs specific arguments as to why SLOTs aren't a good fit. I agree with you that they're not always a good fit -- SQLite and libxml2 are good examples you gave downthread, but the onus is on the one making the proposal. Now, for Python, there's a few disadvantages: * losing the ordering on PV for e.g. has_version (we could add a helper in python-utils-r1 for this); * losing the ability to consistently set package.use/package.env for all Pythons, like always enabling PGO or tests; * disruption to scripts which have reasonably assumed we'd always have a dev-lang/python (we'd need to do something like we have planned for pkgmoves, I think -- make Portage know about it and suggest alternatives intelligently/rewrite it transparently when given as an argument). > This naturally means that only the specific version requested (e.g. via > targets) would be installed, and no cross-slot autoupgrades would > happen. Ideally, I'd like to start doing that with Python 3.14 whose > first alpha is expected next week. Depending on how they handle > freethreading, we'd end up having the first or both of: > > dev-lang/python3_14 > dev-lang/python3_14t > It's worth noting that we *do* this for pypy, but we retain dev-python/pypy3. I'm not a huge fan of it there but I know why we have it -- so that one can test new versions of pypy in parallel even when they supply the same implementation/version of the Python language. > (Alternatives: python-3_14, python-freethreading-3_14? Though I think > following PYTHON_TARGETS is cleaner here.) > > As a side notice, the existing versions would probably remain as-is > until removal, since there's really no gain in splitting them, given > we'd have to retain compatibility with existing depstrings. > > Comments? thanks, sam