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

[Sam James <sam@gentoo.org>]

Mitchell Dorrell <mwd@psc.edu> writes:

> How will the upgrade path look, from e.g. 3.16 to 3.17? What will the typical Gentoo user experience be? What will the
> experience be for a Python developer with a local overlay containing custom Python packages?

It should be transparent because PYTHON_COMPAT will handle that as usual
for a local repository.

The upgrade thing will need testing just to make sure nothing odd
happens though.

>
> I didn't like this idea at first, but I'm warming up to it.
>
> On Sat, Oct 12, 2024, 06:05 Michał Górny <mgorny@gentoo.org> wrote:
>
>  On Sat, 2024-10-12 at 11:59 +0200, Ulrich Mueller wrote:
>  > > > > > > On Sat, 12 Oct 2024, Michał Górny wrote:
>  > 
>  > > 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
>  > 
>  > That other distributions do it that way is not an argument because most
>  > other distributions don't have slots.
>  > 
>  > > 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
>  > 
>  > IMHO this would abuse the package name for information that absolutely
>  > doesn't belong there. It belongs in PV or SLOT.
>  > 
>  > To me it seems that you try to work around a problem (greedy upgrade
>  > behaviour) that should really be solved in the package manager.
>
>  In my opinion, it's the other way around.  We have slots, that are a fit
>  solution for packages that are roughly compatible between every major
>  release, and we keep abusing them for every single thing we can bend
>  enough to make it fit.
>
>  Greedy upgrade behavior makes sense when you have packages where :=
>  and :* operators are applicable.  It doesn't make sense when every
>  single dependency is expected to specify an explicit slot.  In fact,
>  when you are never supposed to depend on the package without specifying
>  a slot, why would you think slots are the right solution?
>
>  In fact, the "freethreading" variation already implies that there could
>  be more than one "slot" per package version.
>
>  It's as meaningless as having sqlite3 packaged as sqlite:3, or gtk that
>  is now randomly split between gtk+:2, gtk+:3 and gtk:4.
>
>  -- 
>  Best regards,
>  Michał Górny