How should a lockfile PEP (665 successor) look like?

[pradyunsg (Pradyun Gedam)]

I was looking at this issue yesterday, to see what we should do about it. See:

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

Honestly, I think the key think is for any new PEP to start from a very clear and well-defined list of scenarios that it is designed to support/address. This was where I felt PEP 665 fell down, it focused on reproducibility, rather than on specific use cases. And as a result, it was extremely hard to determine whether it intended to handle particular scenarios. For example, I never really got a clear answer on whether the PEP was intended to support deployment of an app to a service like Herok…

FWIW, I’m starting to feel like it would make sense to do a one-shot approach for designing the lockfile format since the standardisation process for this, is going to be really slow.

There’s two areas where improvements could be made over PEP 665 in a follow up are – support for source distributions and a clearer story for multi-platform locking. Beyond that, I think we need to (a) clarify the user workflows and how the lockfile fits within it and (b) establish the gradient of support across tooling and design to ensure that the user experience is still good.

This is basically a complicated design problem and a whole bunch of talking to people to establish where things should end up, before we even get to the point of being a publicly posted PEP draft.

Picking this back up is on my TODO list, but there’s a single-digit number of items before it and some of them have a similarly large scope. If someone wants to start chipping away at this before I can, I welcome that and would be happy to help (assuming that help is welcome, of course).