PEP 777: How to Re-invent the Wheel

Given that this is a standards compliance issue, rather than a pip specific one, such a document should be hosted somewhere else (probably in the packaging guide) so that other installers like uv can link to it as well.

But the important thing is what would that document say? Do we simply say “upgrade your installer” and offer no solution for people who can’t do that? Or do we try to offer help to the user to get things working again?

There’s also the question of what scenarios we consider worth addressing. Suppose there’s a new wheel version that adds symlinks, and binary wheels that include C code need that feature to do the .so file versioning thing that Linux does. So a project uploads a sdist, a pure Python wheel, and a wheel containing accelerated C code for certain platforms. The accelerated wheels use the new wheel version, but the pure Python one doesn’t need the feature and so is a version 1 wheel. In that situation, how does the user get a valid install (which would use the pure Python code if their installer didn’t understand wheels with symlinks)? Do we simply say “sorry, you’re out of luck”? Do we tell the user to ask the project not to do this? Do we pretend we hadn’t thought of this possibility and just not mention it?

1 Like