On Wed, Aug 29, 2018 at 1:38 AM Nathaniel Smith <njs@pobox.com> wrote:

The official Tensorflow wheels flat out lie about being manylinux
compatible, and the Tensorflow team has never talked to anyone about
how to fix this, they just upload them to PyPI and leave others get to
deal with the fallout [1]. That may well be what's best for their
users, I don't know. But stuff like this is normal, it happens all the
time, and if someone does it with __array_function__ then we have no
leverage.

Yes, this is a good example of how library authors sometimes break rules imposed by their dependencies when not enforced by technical means.

I'd like to think the TensorFlow team was making an intentional choice here and is willing to live with the consequence of their decision. Unfortunately right now many of those consequences are imposed on others, so this was certainly an inconsiderate choice. I don't know if they were aware of these costs that they are imposing on the rest of the Python ecosystem. I don't see any mention in PEP-513 about the consequences of lying about manylinux compatibility -- even though arguably such warnings should not be necessary.

One lesson we might take from this is documentation is essential: we should have more prominent warnings in NEP-18 (given that it's also likely to serve as a form of user-facing docs) about how experimental this protocol is, and about the specific types of changes we anticipate in the future (e.g., see my other email).

I also hope that Python packaging maintainers would not hesitate to break this abuse of the manylinux1 tag, e.g., if they wanted to add compatibility checks on wheels when uploaded to PyPI.