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) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id D1F9C158046 for ; Mon, 14 Oct 2024 04:09:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DE506E0875; Mon, 14 Oct 2024 04:09:31 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (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 7DDCDE085A for ; Mon, 14 Oct 2024 04:09:31 +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: <9458461d22d6d8969643d8d1164b0bb0f06cd1fd.camel@gentoo.org> (=?utf-8?Q?=22Micha=C5=82_G=C3=B3rny=22's?= message of "Mon, 14 Oct 2024 05:49:25 +0200") Organization: Gentoo References: <87o73nldj7.fsf@gentoo.org> <9458461d22d6d8969643d8d1164b0bb0f06cd1fd.camel@gentoo.org> Date: Mon, 14 Oct 2024 05:09:27 +0100 Message-ID: <87cyk3l408.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: fef5e2f6-07c3-4bbc-974c-1fd0aba6b00a X-Archives-Hash: 9bbc57db709dbe0de7a51d78d0559780 Micha=C5=82 G=C3=B3rny writes: > 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 versio= n, >> > 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. Not for the sake of it, I was thinking of: if has_version >=3Ddev-lang/python-3.10 ; then # Skip bogus tests relying on legacy behaviour fi but of course, that doesn't work for pypy, which I forgot about ;) > >> * 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. You can't wildcard on it, though, so you have to explicitly list it for all Pythons. I'm not sure what you mean by the consistency point. You can restrict it right now if you want to via slot or version ranges, but we have no way of doing a wildcard on package name? (I actually think we could do with wildcard matching on version at least in /etc/portage but finding some syntax which is free for it isn't easy. It would be useful for e.g. masking .0 kernels.) > >> * 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. Ah, good point.