When macOS switched from the 10.x series to the new versioning scheme incrementing the major version with macOS 11, packaging and subsequently pip and uv decided to only emit tags with the minor version 0 for macOS 11+, since we don’t know how many minors each version has. This means that only macosx_{major}_0 platform tags work, other minor versions will mismatch.
If this limitation remains, it seems reasonable to document it with at least a warning somewhere indeed.
Codifying this as the design seems more questionable, since it was a pretty ad-hoc decision in the packaging library, and it could be changed/improved. The most relevant issue is Missing valid mac tags · Issue #578 · pypa/packaging · GitHub I believe. Most participants there agree that adding support for minor versions makes sense, it’s just work and the current packaging design of pre-generating a full list of valid versions is getting in the way a bit.
I’m impartial to which version we pick. Unless someone has a strong motivation about changing this now, would it be possible to separate being consistent about the current de-facto standard throughout the ecosystem from changing it?
Specifically, I’m thinking about documenting this as current behavior on packaging.python.org and blocking uploads on PyPI (Codify that macOS platform tags use minor version 0 for macOS 11+). Both of those are reversible, we can extend the set of allowed and supported platform tags without breaking users (the wheels will be ignored by older pip versions). For the documentation, I’m planning to add a disclaimer that platform tags are subject to change, similar to this paragraph from std::io - Rust :
Note, however, that this is informative, not a binding contract. The implementation of many of these functions are subject to change over time and may call fewer or more syscalls/library functions.
The current state is that there is a de-facto standard set by packaging (and pip and uv), but users aren’t informed about it (no info on packaging.python.org), and users don’t get warned that their packages are broken (no pypi.org error): A worse user experience than either having or not having minor version tags consistently. I’m not trying to preclude consensus or trying to make something more official that it is, but trying to make the best out of https://github.com/pypa/packaging/pull/319 effectively having made a decision in that PR, this being adapted in pip and uv, while packaging.python.org hasn’t been updated.
that sounds perfectly reasonable to me, as does your plan on what to change right now.