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 C5802158046 for ; Mon, 14 Oct 2024 03:49:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0A3AAE0856; Mon, 14 Oct 2024 03:49:31 +0000 (UTC) Received: from smtp.gentoo.org (dev.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 56534E0821 for ; Mon, 14 Oct 2024 03:49:30 +0000 (UTC) Message-ID: <9458461d22d6d8969643d8d1164b0bb0f06cd1fd.camel@gentoo.org> Subject: Re: [gentoo-dev] [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14 From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Cc: python@gentoo.org Date: Mon, 14 Oct 2024 05:49:25 +0200 In-Reply-To: <87o73nldj7.fsf@gentoo.org> References: <87o73nldj7.fsf@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-3Llh+HVAXsBHbxpHhQQ1" User-Agent: Evolution 3.52.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: 32e6591a-b4a7-408c-b1dd-97318ffd611f X-Archives-Hash: 8e132f51dc10be35f6d69916b984ddd3 --=-3Llh+HVAXsBHbxpHhQQ1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2024-10-14 at 01:43 +0100, Sam James wrote: >=20 > > 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.: > >=20 > > dev-lang/python3_N > >=20 >=20 > 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. >=20 > 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); I don't get this. You can't use has_version directly without specifying the slot, because it's going to match different versions. And there's no real difference between specifying a slot and a different package name. Well, unless you mean doing a meaningless has_version match for the sake of it. Then, yes, unslotting fixes that -- i.e. removes that ability. > * losing the ability to consistently set package.use/package.env for all > Pythons, like always enabling PGO or tests; We aren't losing it, you just need to repeat it. Just like right now you can apply these per-slot or restrict version ranges, so there's no guarantee of consistency either. > * 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). Yes, this is a fair point, and the logic in pkgcheck is pretty horibble, so I guess going for slotting just to avoid having to fix that and deploy the fix makes sense. > > 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: > >=20 > > dev-lang/python3_14 > > dev-lang/python3_14t > >=20 >=20 > 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. Technically, we could merge PyPy into a single package, as long as we use verisons such as 2.7.7.3.17:2.7, 3.10.7.3.17:3.10, etc. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-3Llh+HVAXsBHbxpHhQQ1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmcMlMUSHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQO70oH/iUXRFSCYUhd6pEhps15hNUehYQBcm3V wbEDlb2YXHgBmRFQDGjSdoGbCYnnotKgDnNE/ux4EeUvL8oqQIs5kmt7APj1A7KW Pcum0mx39nYszHqYjU9W1GIdrD67Ib7sThwtz7iwyD+QDDtPjCo8aSyzJ0FNXCn7 dxchN94Bm3EJghr1RSJojZxYdRgN7m7L1a3J/l+M4nbIAkqfuL0CaF28LlHVDtqI lgyfXw+iupDZgZ3jM1Sk+A58yfUFv+cGULRnxnJt7SFxDD/cDAmIs7k+dr2xV/U2 zpvXwFrswe5FAXBe9iPbXGyuuaX9v94PE9W17LwsWj+W92YgBR+z2gM= =XpRk -----END PGP SIGNATURE----- --=-3Llh+HVAXsBHbxpHhQQ1--