ALSO super quickly, @bernatgabor and I had a text chat elsewhere about this and here’s my summary of it: (they OK’d me to post a summary, but might want to correct me if I’m wrong below)
- If
tree → wheeldiffers in behavior totree → sdist → wheel, there’s a decent chance that the PyPI uploads are broken, if the maintainer isn’t usingtox/check-manifest. And if the sdist is broken but not the wheel, that’s even less likely to be found until later – since pip will default to wheel installs.- Note that the failure is not at build time – but rather when installing from sdist.
- There are no guarantees that the result of
build_sdist→ unpack →build_wheelshould be the same asbuild_wheel. It’s reasonable to expect it to be. But it’s not required by the PEP. Maybe, we should modify the PEP to explicitly make this a guarantee that the backend must provide/maintain.
- Every subprocess call involves significant overhead as the interpreter needs to initialize itself all over again
- Doing the extra sdist step makes pip behave more like a distribution validation tool, rather an installation one
- check-manifest exists because setuptools is bad at this
- improve setuptools be better at this
- check-manifest exists because setuptools is bad at this
- The backend should take ownership of its correct behaviour. It would be preferable to have a tool built, that allows users to do such validations, rather than pip doing it on all systems, all machines, all the time