Things have settled down here, so I think it’s time to drive towards closing out the open issues. Here they are. Any we can’t reach consensus around will be decided by the authors of the PEP.
Allow for Tool-Specific
It has been suggested to allow for custom
type values in the
code table. They would be prefixed with
x- and followed by
the tool’s name and then the type, i.e.
x-<tool>-<type> . This
would provide enough flexibility for things such as other version
control systems, innovative container formats, etc. to be officially
usable in a lock file.
Support Variable Expansion in the
This could include predefined variables like
PROJECT_ROOT for the
pyproject-lock.d so URLs to local directories
and files could be relative to the project itself.
Environment variables could be supported to avoid hardcoding things
such as user credentials for Git.
Don’t Require Lock Files Be in a
It has been suggested that since installers may very well allow users
to specify the path to a lock file that having this PEP say that
"MUST be kept in a directory named
pyproject-lock.d " is pointless
as it is bound to be broken. As such, the suggestion is to change
“MUST” to “SHOULD”.
Record the Date of When the Lock File was Generated
Since the modification date is not guaranteed to match when the lock
file was generated, it has been suggested to record the date as part
of the file’s metadata. The question, though, is how useful is this
information and can lockers that care put it into their
table instead of mandating it be set?
Locking Build Dependencies
Thanks to PEP 518, source trees and sdists can specify what build
tools must be installed in order to build a wheel (or sdist in the
case of a source tree). It has been suggested that the lock file also
record such packages so to increase how reproducible an installation
There is nothing currently in this PEP, though, that prohibits a
locker from recording build tools thanks to
as the entry point for calculating what to install. There is also a
cost in downloading all potential sdists and source trees, reading
pyproject.toml files, and then calculating their build
dependencies for locking purposes for which not everyone will want to
pay the cost for.
Requires-Dist Input to the Locker’s Resolver
needs key allows for recording dependency specifiers,
this PEP does not currently require the
needs key to record the
Requires-Dist metadata that was used to calculate the
lock file. It has been suggested that recording the inputs would help
in auditing the outcome of the lock file.
If this were to be done, it would be an key named
lived along side
needs and would only be specified if it would
differ from what is specified in