Re: [gentoo-dev] [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14

[Eray Aslan <eras@gentoo.org>]

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