> So we either have to shrug and say, "don't use sdists if you want reproducible builds,"
What is this, I can't even... How can anyone expect to have a reproducible build's artifact if they downloaded the source?
Now, and most importantly, all this talk is about "pure" (as in Python-only) packages. This is, practically, worthless for most real Python projects because those rely on native bindings. Why should anyone expect PyPI to be able to build those if no standard procedure exists for building them is beyond comprehension.
For projects with native bindings you can still fairly trivially solve this with SBOMs, and some Linux distributions are doing this for many years now. The compiler is a dependency that needs documenting, and they explicitly write they need means to re-create the documented environment from that SBOM.
Sounds risky, unless paired with strong policy about what a verifier should do. e.g. if the verifier just grants network access to the buildbot that then checks what the result should look like, then compromise could remain invisible while the label silently downgrade to "independently downloaded by". And I do not expect there are many parties that would be willing to provide such service beyond their own needs, while simultaneously not already providing that service in places where the infrastructure and policies are already set (such as Debian). Or at least they would already contribute towards build dependencies that do not break reproducibility on every other version bump.
Whether the code in the SBOM subvertly downloads additional code (during build time or later during runtime) is still for the code reviewer to be found.