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

Also, following on from my posting in this topic, I would like to discuss in a bit more detail the transition plan here. I don’t consider this a mandatory part of the PEP (as I posted that note after this PEP was developed) but I think it would be useful as a supporting discussion. Points I think it would be useful to cover include:

  • What would be key milestones in the process of moving from the current situation (tool-specific lockfiles, based mostly on the requirements format) to widespread adoption of PEP 665 lockfiles? Which tools are the most critical when it comes to adopting PEP 665?
  • How would individual projects move to PEP 665 lockfiles once their tools support that format? And of course, how do they check whether PEP 665 lockfiles fit their workflow in the first place?
  • How can the packaging community work to get to a position where cloud providers like Heroku and Azure support PEP 665 as a primary deployment format?

In future PEPs, as I noted, I would like to make it an explicit requirement to cover this subject, so we could consider this as a “practice run” of the process :slightly_smiling_face: