PEP 600 text and example code for "Package installers" section disagree

Packaging
1

Looking at PEP 600 – Future ‘manylinux’ Platform Tags for Portable Linux Built Distributions | peps.python.org in the " Package installers" section, it reads:

In addition, we follow previous specifications, and allow for Python distributors to manually override this check by adding a _manylinux module to their standard library. If this package is importable, and if it defines a function called manylinux_compatible, then package installers should call this function, passing in the major version, minor version, and architecture from the manylinux tag, and it will either return a boolean saying whether wheels with the given tag should
be considered compatible with the current system, or else None to indicate that the default logic should be used.

However, the example code in the section below only calls the override function after several checks happen, all of which return False. Those checks cannot be overridden as-is, and the end result is that real-world code that follows the provided example usage of the manylinux_compatible function only let the user disallow packages that would have been allowed by default; they do not permit the function to allow packages that would be disallowed by default (exceptions to this around manylinux1_compatible exist, but that’s not the focus here).

This is a problem when packages are being prepared in an environment that differs from the environment that the packages will be run in. Specifically, Bazel’s rules_python implementation installs packages using a python interpreter from the system, even if the programs will be run using a Bazel-built python that is built and run with a newer glibc than the system default.

Would it be reasonable to change the code to better match the behavior described text? Or is the text not accurately describing the intent?

3 Likes
2

Checking the equivalent example code from back in PEP 513, the suggested order of checks in the PEP 600 sample code is definitely not correct: PEP 513 – A Platform Tag for Portable Linux Built Distributions | peps.python.org (note that the glibc version check there is after the override check, not before it).

So yeah, that looks like a genuine bug in the sample code to me (and from the question, it sounds like the bug has been propagated to actual installers).