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
