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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)