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 (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 2DD10158046 for ; Sat, 12 Oct 2024 09:49:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0E459E29EF; Sat, 12 Oct 2024 09:49:30 +0000 (UTC) Received: from dsona.a21an.org (dsona.a21an.org [139.162.188.118]) (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 B9CCEE29CB for ; Sat, 12 Oct 2024 09:49:29 +0000 (UTC) Received: from rog.a21an.org (p200300f1c71d6b333b7396fd371382f4.dip0.t-ipconnect.de [IPv6:2003:f1:c71d:6b33:3b73:96fd:3713:82f4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dsona.a21an.org (Postfix) with ESMTPSA id 4XQdxg5Ks0z29bC for ; Sat, 12 Oct 2024 09:49:27 +0000 (UTC) Date: Sat, 12 Oct 2024 11:49:17 +0200 From: Eray Aslan To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14 Message-ID: References: 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.2.13 (2024-03-09) X-Archives-Salt: da0edaa2-8d20-4795-8713-78861963e59c X-Archives-Hash: 79a37aed13d8091265bce5f2ca5130e7 On Sat, Oct 12, 2024 at 10:12:56AM +0200, Michał Górny wrote: > Historically, all versions of CPython were slotted in a single package, > i.e.: > > dev-lang/python:3.N > > 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. > > 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! > > 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 FWIW, if I were to start anew, my ideal env would probably be: 1/ keep N versions of python installed all the time 2/ give the option to define N with sane defaults and limits 3/ upgrade greedily 4/ give the option to define upgrade behaviour (switch default python interpreter to newest, no change, no change unless no longer in the tree etc) 5/ do not change from free-threaded to regular GIL versions or vice versa automatically. keep to one lane (this might even apply to jits so perhaps make it easy to define lanes) 6/ make it easy to create virtualenvs with any python interpreter 7/ make it easy to change between any python interpreter and set a default Your proposal is close. It would require some (minimal) manual work but that is reasonable afaic > 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 > > (Alternatives: python-3_14, python-freethreading-3_14? Though I think > following PYTHON_TARGETS is cleaner here.) dev-lang/python3_14t is a better looking option imho > 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. so no dev-lang/python3_13t? nothing crucial but would have been nice > Comments? Thanks for doing this -- Eray