Mitchell Dorrell <m...@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 <mgo...@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
