Pre-PEP: Include pylock.toml files inside wheels

[Kound (Carli* Freudenberg)]

@pf_moore

Nobody ever asked for requirements files (with pinned dependencies) to be shipped in wheels. I find it difficult to believe that this use case has suddenly appeared, right when lockfiles get standardised. So I have to ask, what were people doing about this before lock files - and why can’t they carry on doing that?

This is a coincidence: A organisation I work for is currently NOT using pinning at all, it is mostly regulated by limiting existing packages on different indexes: An increasing pain point and my TODO list for long.
I happens to be that I just visited the Europython to learn about the new standard.
Learning also about SBOMs / PEP 725 and having already a package index that is secured (i.e. only specific customers can access specific projects/weels), putting the lock file in the wheel just felt like a too good fit.

@pf_moore

It’s a confusion of abstract vs concrete requirements in my opinion.

Coming from all the problems with breaking dependencies I really hope that I do not confuse things there. But I will cycle back with some colleagues to make sure.

@pf_moore

Come to that, why isn’t the lockfile on its own sufficient? Maybe the UI should actually be pipx run http://url/to/pylock.toml

Because then we loose the package manager feature like, installing a specific version of the application and need to create yet another service to manage and distribute the lock files.
The problem I want to solve is how to easily distribute a versioned lock file without:

• writing another package manager
• and it’s service counterpart
• teach users how to use it
• define what a release it and how to sync it with the wheel package release

@pf_moore

For a start, would the lockfile include the containing wheel itself?

That is an interesting question. From an installation perspective I would say, no, it doesn’t. It would create a chicken egg problem, as it would need to know it’s own hash and url. Using a lock file of a wheel implicitly install this wheel.
From a perspective after installation, it make the lock file quite useless when copied into site-packages.
So we should look into that and possible use case (what could people using the site-packages version of the lock file for, if at all? Can we simply not copy it?).

@pf_moore

If we want a lockfile-based equivalent [to pipx/uvx install that resolve packages/…] then we should redesign the model based around lockfiles

Can you specify what you mean by that?
I mean of course we could define “pylock applications” that would do something similar. But is there any advantage/use case that can be solved only with this kind of model? I can’t think of any but on the contrary fear would increase complexity and confuse users: I.e. airflow has version 3.4.1 but the locking has the version 3.0.1. Which airflow version is installed with the locking?
Is it the most current version or did they simply forget to update/publish the locking?
I just feels easier to glue the lock file and the wheels together.

@pf_moore

and probably locking a particular Python interpreter version as well, if we want reproducibility

That is part of my the suggestion, even if its not that strict formulated. Normally packages are tested against a ranger of interpreters, therefore IMHO it is fine to allow the tested range.
Also interpreters, can be harder to install/obtain in some environments^[1]`.

---

1. In our organisation we only want a specific python interpreter version to prevent develops from using features that are not compatible with all deployments and therefore disable uv’s python installer. Also standalone interpreters have some quirks, which make python interpreter installation yet another can of worms that don’t want to solve with this PEP. ↩︎