PEP 751 "A file format to record Python dependencies for installation reproducibility" (https://peps.python.org/pep-0751/) is essentially a proposed ecosystem-wide standard format for lock files for Python projects.
While I'm still not convinced that most people really need all the features of a general purpose lock file for their individual use cases, it does make sense to have a format which includes (or can include "everything". Conceptually this creates a logical, semantic separation between abstract immediate dependencies (in a `pyproject.toml` file) and resolved, concrete, transitive dependencies in the lock file.
For example, an installer could recognize that it's been given the latter, and skip the steps to re-compute a package resolution that won't change anything. (Although that doesn't help much for updating an existing environment - since you have to check for conflicts with the existing packages, and decide what to do if you find one.) Build backends (when the package is for an "application") could verify that the `pyproject.toml` abstract dependencies are solved by the lock, and then list the concrete dependencies in core metadata (PKG-INFO for an sdist or METADATA for a wheel) instead of leaving the abstract ones alone. But there's an issue here: an installer wouldn't know that these dependencies have already been resolved, because the distinction between `pyproject.toml` and `pylock.toml` has been lost. It seems like `pylock.toml` is intended as a development tool, not as alternate metadata that would be included in a wheel. Although installers that have a separate concept of "installing applications" could presumably be directed to look at `pylock.toml` if it were included in a wheel - for a directly specified single package, not for its dependencies.
> One could see writing out wheel file details as a table keyed on the file name. For example ... Itβs entirely a structural change which some may (not) prefer.
I'm strongly in favour, since this would allow writing the data without an inline table. Brett Cannon suggests that the current
[[packages]]
# other information about the package here
wheels = [
"attrs-23.2.0-py3-none-any.whl" = {upload-time = 2023-12-31T06:30:30.772444Z, url = "https://files.pythonhosted.org/packages/e0/44/827b2a91a5816512fcaf3cc4ebc465ccd5d598c45cefa6703fcf4a79018f/attrs-23.2.0-py3-none-any.whl", size = 60752, hashes = {sha256 = "99b87a485a5820b23b879f04c2305b44b951b502fd64be915879d77a7e8fc6f1"} }
]
could become
[[packages]]
# other information about the package here
[packages.wheels]
"attrs-23.2.0-py3-none-any.whl" = {upload-time = 2023-12-31T06:30:30.772444Z, url = "https://files.pythonhosted.org/packages/e0/44/827b2a91a5816512fcaf3cc4ebc465ccd5d598c45cefa6703fcf4a79018f/attrs-23.2.0-py3-none-any.whl", size = 60752, hashes = {sha256 = "99b87a485a5820b23b879f04c2305b44b951b502fd64be915879d77a7e8fc6f1"}
but seems to overlook that, thanks to the flexibility in the TOML spec, it could also become
[[packages]]
# other information about the package here
[packages.wheels."attrs-23.2.0-py3-none-any.whl"]
upload-time = 2023-12-31T06:30:30.772444Z
url = "https://files.pythonhosted.org/packages/e0/44/827b2a91a5816512fcaf3cc4ebc465ccd5d598c45cefa6703fcf4a79018f/attrs-23.2.0-py3-none-any.whl"
size = 60752
hashes.sha256 = "99b87a485a5820b23b879f04c2305b44b951b502fd64be915879d77a7e8fc6f1"
which I would say is far easier to read. I would consider this a straightforward application of the "flat is better than nested" principle; while the data is inherently nested, its representation doesn't need to be.
On reflection (and testing), my thought here doesn't stand up. Or rather: I still like writing the data without inline structures, but it doesn't require changing [[packages.wheels]] to a table.
TOML perfectly allows for arrays-of-tables to be put within arrays-of-tables, without any inline syntax, so we could just as well have:
[[packages]]
# other information about the package here
[[packages.wheels]]
name = "attrs-23.2.0-py3-none-any.whl"
upload-time = 2023-12-31T06:30:30.772444Z
url = "https://files.pythonhosted.org/packages/e0/44/827b2a91a5816512fcaf3cc4ebc465ccd5d598c45cefa6703fcf4a79018f/attrs-23.2.0-py3-none-any.whl"
size = 60752
hashes.sha256 = "99b87a485a5820b23b879f04c2305b44b951b502fd64be915879d77a7e8fc6f1"
In TOML, subsequent `[[packages.wheels]]` tables would specify another wheel for the most recently mentioned package; `[[packages]]` would close off the details (including wheels) for a package and start the next one.
While I'm still not convinced that most people really need all the features of a general purpose lock file for their individual use cases, it does make sense to have a format which includes (or can include "everything". Conceptually this creates a logical, semantic separation between abstract immediate dependencies (in a `pyproject.toml` file) and resolved, concrete, transitive dependencies in the lock file.
For example, an installer could recognize that it's been given the latter, and skip the steps to re-compute a package resolution that won't change anything. (Although that doesn't help much for updating an existing environment - since you have to check for conflicts with the existing packages, and decide what to do if you find one.) Build backends (when the package is for an "application") could verify that the `pyproject.toml` abstract dependencies are solved by the lock, and then list the concrete dependencies in core metadata (PKG-INFO for an sdist or METADATA for a wheel) instead of leaving the abstract ones alone. But there's an issue here: an installer wouldn't know that these dependencies have already been resolved, because the distinction between `pyproject.toml` and `pylock.toml` has been lost. It seems like `pylock.toml` is intended as a development tool, not as alternate metadata that would be included in a wheel. Although installers that have a separate concept of "installing applications" could presumably be directed to look at `pylock.toml` if it were included in a wheel - for a directly specified single package, not for its dependencies.