PEP 665, take 2 -- A file format to list Python dependencies for reproducibility of an application

[barry (Barry Warsaw)]

@pf_moore

Reproducibility was the key feature targetted by PEP 665, and in that context sdists are the showstopper. Other people were insisting that sdist support was mandatory, but they weren’t too concerned about (absolute) reproducibility, being more interested in having something that replicated the “fully pinned requirements file” model as far as I could tell.

Which points to a reasonable trade off ^[1]…

@groodt

Guarantee reproducibility if there is a single sdist in the transitive closure for a target platform

Yep. I’d be fine with having a format which allows me to turn the knob in one direction or the other, with sufficient UX to give me the feedback I need to know if the package manager isn’t able to do what I want.

E.g. If I want near perfect reproducibility ^[2] then I’ll specify wheels and the package manager should refuse to install sdists, or warn if it can’t resolve everything through wheels, or just fall back to “close enough” reproducibility if it has to resolve via sdists.

---

1. to me at least ↩︎

2. it’s probably impossible to get bit-for-bit checksum equal reproducibility without more infra that’s out of scope here ↩︎