To be clear, I don’t think perennial manylinux should be accepted without user-friendly build profile aliases as an inherent part of the specification. I can understand “manylinux2014 targets distros released since 2014 or so, and excludes older distros”, but as a human attempting to make publishing compatibility trade-offs rather than a computer trying to install packages, “manylinux_glibc_2_17” doesn’t tell me anything useful. I think that readability trade-off would be an OK one to make in archive filenames, but not in tooling interfaces.
The idea of moving the build profile definitions out of pip core in order to ease future rollouts is an interesting one, though. That could be done in a couple of different ways:
- amending the simple API to include an extra metadata file (potentially tricky to evolve over time, but theoretically no harder than evolving a Python API. Definitely harder to roll out though, since we’d need to update all simple API implementations, not just PyPI)
- creating and publishing a new “wheel_build_profiles” package that serves as a perennially updated map from wheel naming conventions to installation target checking heuristics.
Updating “wheel_build_profiles” to a new version could then be as routine a task as updating to a new timezone database, such that even highly conservative distros would be willing to keep it up to date.