@pfmoore question from a governance perspective, as PEP-0776 is to be split into two parts (packaging & non-packaging). Do you have similar thoughts here? The PEP proposes both a new sys.abi_features attribute and a new sys_abi_features environment marker.

Unfortunately, I think it does.

It may be possible to handle the new marker without a second PEP - I'd be willing to support adding sys_abi_features to the marker spec as a simple update to the specification. It would still need raising on the packaging Discourse, though. And there would be questions about how tools running under versions of Python without the new sys attribute should handle the marker, so it's not completely uncontroversial.

Looking at the PEP itself, I see that it introduces the idea of markers which are set objects. That's something that PEP 751 also introduces - the PEP authors here should probably look at PEP 751 (which is currently being reviewed for approval by me) to ensure they don't contradict what's being said there. I think it's compatible, but I haven't checked thoroughly.

It might make sense to treat this only as a packaging PEP, since the changes to CPython itself seem small enough to be handled without a PEP. So the approval process would be a packaging PEP for the new markers, plus standard core dev consensus for the related CPython changes.

That's also a reasonable approach.

Taking the last few comments to their extreme, we could make the core change without a PEP, and agree the packaging spec change can be done without a PEP as well. I think that's probably going a bit too far, though 🙂

Thanks for the feedback, that makes sense!

Shall we then discuss this as a packaging PEP and once we have community agreement on names and content make the necessary additions to CPython?

It'd be nice to unresolve this comment, since it was just brought up again on Discourse.