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

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2772 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 512 bytes --]