Pip build isolation vs. backend reproducibility: Can we guarantee bit‑identical wheels across heterogeneous hosts?

Pip’s build isolation, mandated by PEP 517, creates a temporary environment that installs only the build-system.requires dependencies before invoking the chosen backend. The isolation covers Python packages only; system libraries (OpenSSL, glibc, libffi) and compiler toolchains remain host‑provided, so the resulting wheel’s manylinux tag can drift between Debian‑bookworm, Ubuntu‑24.04, or macOS builds.

Backend behavior also diverges: setuptools respects pyproject.toml strictly, whereas flit and poetry‑core may embed VCS‑derived version strings unless SOURCE_DATE_EPOCH is set, breaking bit‑for‑bit reproducibility. Pip’s --no-build-isolation flag, while convenient for local dev, re‑introduces host contamination.

No standard mechanism exists to declare system‑level build requirements in pyproject.toml, and lock file formats differ between pip, uv, and Poetry. This raises the question of whether truly repeatable wheel artifacts can be produced across heterogeneous hosts with the current standards.

Which additional metadata fields could be added to pyproject.toml to capture system‑level build requirements?
How can we enforce a consistent manylinux tag across different base images?
Is there a standardized lock file format that both pip and uv can consume to guarantee identical dependency graphs?