I saw just as I was going to bed last night that @pf_moore mentioned me as potentially being able to clarify some things here. As I still don’t have a strong preference one way or the other, let’s see if I can bring clarity on a couple of points.
- I think calling auditwheel profiles ‘implementation defined’ makes the idea sound worse than it is, although it’s perfectly true in a literal sense. Auditwheel exists as a way to define these library & symbol profiles in a format usable in code, along with some utilities that make use of them. The definitions exist as JSON within the package. Maybe it would be clearer if the definitions were packaged separately from the code to check & repair wheels against them, but in either case, it’s not ‘implementation defined’ in the same way that, for instance, the behaviour of
setup.pyis. - I think Nathaniel’s saying that the functional definition of what external libraries a wheel can rely on is “those that exist and are stable on mainstream Linux distributions with at least glibc 2.x.” We can come up with a list as a hint, but if we discover that e.g. Fedora is missing something on the list, we remove it from the list rather than saying “manylinux X wheels don’t work on Fedora”. So the list is advisory, not definitive. But this would mean that you can never definitively know that a wheel is manylinux X compatible, only that it satisfies the current recommendations. I’m not entirely comfortable with this, which is why my draft of the PEP is framed around auditwheel profiles as definitive.
In light of @gunan’s post, I’ll also plug once more my idea for a compromise. Why don’t we define a new explicit profile in a PEP (satisfying those who want to make the next manylinux available ASAP), but switch to a versioning scheme based on glibc version numbers, so we can work towards pip recognising future tags without needing an update for each profile.