Folks at my company want to create a single lock file that is usable on any supported architecture.
I think this means the superset (per-package) flavour in this spec.
In our case, it’s always CPython, 64-bit, Linux, but processor architecture vary.
A couple of caveats have been brought up:
- some pypi packages ship wheel for some architectures but not others
- rarely, a different dep version is installed, e.g. amd64 → 2.14.3 and arm64 → 2.14.2
Most importantly, we want to avoid behaviour like pip-tools (?) where our build system needs to run on e.g. RISC-V in order to produce a lock file that works on RISC-V.
In simpler terms, I want to cook up lock files on my laptop.
Context: individual packages’ requires-python for CI (per-file) scenario.
I disagree. The lock file is built for a concrete application, which declares specific supported range of Python versions.
It feels like gold-plating. I would argue that the lock file should only contain what’s needed to install packages. I think that if there’s a field that can be changed without affecting the final outcome, that is installation(s), that field should be omitted. IMHO, the lock file should be stamped with python version spec at the top only.
There’s a precedent, of course, poetry.lock contains python-versions spec for each dependency. Then again, poetry’s approach is a bit redundant, when the lock file has a hash of the “essense” of pyproject.toml and yet copies top-level python-versions field. And, apparently, poetry performs some dependency resolution at install time, doesn’t it?
Anyway, the field is optional in the PEP, it’s up to lockers to choose to emit it.
All in all, my gut tells me that the locks files are not really human-readable, not for large projects. Rather, they are machine-readable and human-inspectable.