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

[brettcannon]

@pf_moore

OK, but sdist support is covered by the PEP, at least to the extent that it is currently an open issue

Sure, but the rest of the PEP is written as if sdists are not supported.

@pf_moore

So there will certainly have to be some information in the PEP, even if the implementation details remain open.

Yes.

@pf_moore

I’d expect that when sdists are moved to the “rejected ideas” section (assuming that’s what happens), the following points would be made

Assuming Supporting sdists and source trees in PEP 665 doesn’t lead to sdists making into this PEP, I would summarize what’s there which includes what needs to be resolved by any future PEP.

@pf_moore

I’d also like to see (assuming sdist support gets rejected) an explicit paragraph in the motivation section explaining that the PEP chooses to only support wheels because that allows reproducibility to be guaranteed without needing build systems to provide reproducibility guarantees as well (which, as far as I know, none of them formally do). I think that would make the current emphasis in the PEP on reproducibility less distracting for people who don’t have a strong need for it.

PEP 665 – A file format to list Python dependencies for reproducibility of an application | peps.python.org was meant to capture that, but I can stengthen it a bit to be more explicit about this.