@BHUVANSH855 do you actually have a real-world need for this? You say “a gap that I keep running into”, but there is nothing concrete you mention and you can’t really fix much here beyond getting a better error message. What specifically do you keep running into?
I’ll also note that this is your second proposal in a week for new Core Metadata (a security field being the other one, see here). It all feels a little premature (and AI-driven, as pointed out in the other thread).
It seems to me that this is a lot like upper bounds on python-requires, except the need being less clear. The recommended approach today for that one is: raise a clear error at the top of your build config file, so the user is clear on why the build fails - and not just “PyPy is not supported” but why that’s the case, or link to a tracking issue with discussion if you have one.
An installer can’t do much better: if a package is in a dependency tree, it is needed, so an error message it is. An installer will give an error message a bit earlier, but it’ll be more generic.
I have to say I don’t really understand the link to PEP 725. If the problem would have been “the package does build and work under an alternative interpreter, but a build dependency is missing” then yes sure (concrete examples would help). But that wasn’t the question here - the case provided is “package is CPython-only”.
Which I don’t even think is a well-defined situation. Being compatible with CPython is a key goal of alternative interpreters like PyPy. They succeed in many cases, and when they don’t, it’s often a bug or missing feature on their side that’s fixable. If package metadata would prevent them from even trying to install, it just makes their jobs harder.
Concrete example here: there’s some effort ongoing to make PyPy understand abi3 wheels. Say that works, that’d be a nice achievement. Packages that declare “doesn’t support PyPy” would then be unhelpfully out of date.