Description
When auditwheel performs its search for external dependencies, it currently ignores linkage to libpython. This behavior has existed since the very first commit on the repository. It also seems like some recent changes like #418 have explicitly chosen to preserve this behavior.
I am not sure why auditwheel makes this choice since the original manylinux spec in fact explicitly disallows libpython linkage. That has also been reinforced in more recent iterations of manylinux, e.g. PEP 599 says:
libpythonX.Y remains ineligible for inclusion for the same reasons outlined in PEP 513
Is there a particular reason that auditwheel does not enforce this requirement? Perhaps there are good reasons to exclude this check, at least conditionally.
If not, it should probably be changed, but I would guess that the change might be quite disruptive to projects that have been unknowingly linking to libpython up until now, so such a change would probably need to be rolled out slowly and hidden behind some feature flag to give projects some time to adapt.
I was brought here by astral-sh/python-build-standalone#619. Now that the Python distributions that are installable with uv are statically linking libpython and the DSO is no longer even available in those distributions (precisely the sort of use case that the manylinux requirement is meant to support), various existing wheels that auditwheel would consider valid will fail to load in these environments.