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

[brettcannon]

@pradyunsg

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.

I’m stilling planning to do this in mousebender. Getting packaging.metadata parsing METADATA files is the next step in this work.

@pradyunsg

support for source distributions

I still don’t want to touch that in a v1 as it is an inherent compromise in environment reproducibility.

@pradyunsg

clearer story for multi-platform locking.

Got an idea (What information is needed to choose the right dependency (file) for a platform? is part of it).

@pradyunsg

If someone wants to start chipping away at this before I can

I have a design in my head that would allow for different lock files for different platforms. The steps necessary to get there are:

1. packaging.metadata to read METADATA files
2. Resolver using resolvelib that only considers wheels
3. Tool to generate the lock file(s)
4. Tool to install from the lock file(s)

Steps 2 - 3 I’m assuming will be in mousebender since they are somewhat specific, although I do plan to have this all accessible via APIs.

@ofek

The problem isn’t intractable, but it certainly feels that way so far.

It’s only intractable if you try to please all the people all the time. If you are willing to bound the use-case and how people will interact with the tool you can get a solution, but you have to choose the target use-case first (my design addresses app/cloud/deployment developers).