On Mon, 2024-10-14 at 01:43 +0100, Sam James 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 > > > > As others have noted, such a proposal needs specific arguments as to why > SLOTs aren't a good fit. I agree with you that they're not always a good > fit -- SQLite and libxml2 are good examples you gave downthread, but > the onus is on the one making the proposal. > > Now, for Python, there's a few disadvantages: > * losing the ordering on PV for e.g. has_version (we could add a helper > in python-utils-r1 for this);
I don't get this. You can't use has_version directly without specifying the slot, because it's going to match different versions. And there's no real difference between specifying a slot and a different package name. Well, unless you mean doing a meaningless has_version match for the sake of it. Then, yes, unslotting fixes that -- i.e. removes that ability. > * losing the ability to consistently set package.use/package.env for all > Pythons, like always enabling PGO or tests; We aren't losing it, you just need to repeat it. Just like right now you can apply these per-slot or restrict version ranges, so there's no guarantee of consistency either. > * disruption to scripts which have reasonably assumed we'd always have a > dev-lang/python (we'd need to do something like we have planned for > pkgmoves, I think -- make Portage know about it and suggest alternatives > intelligently/rewrite it transparently when given as an argument). Yes, this is a fair point, and the logic in pkgcheck is pretty horibble, so I guess going for slotting just to avoid having to fix that and deploy the fix makes sense. > > 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 > > > > It's worth noting that we *do* this for pypy, but we retain > dev-python/pypy3. I'm not a huge fan of it there but I know why we have > it -- so that one can test new versions of pypy in parallel even when > they supply the same implementation/version of the Python language. Technically, we could merge PyPy into a single package, as long as we use verisons such as 2.7.7.3.17:2.7, 3.10.7.3.17:3.10, etc. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
