In many projects we are building (scrapers, zimfarm, ... all besides libraries like python-scraperlib), we use pinned dependencies versions to ensure reproducible builds.
But now the ecosystem has changed and pylock.toml format has landed (see https://packaging.python.org/en/latest/specifications/pylock-toml/)
This file would allow to specify range of versions in pyproject.toml for all projects, and use the pylock.toml to have reproducible builds.
This would allow to simplify significantly dependency upgrades since one will just have to update the pylock.toml to most recent version matching pyproject.toml ranges. This is currently done manually and is quite a pain.
Currently, hatch does not support this pylock.toml file, see e.g. pypa/hatch#749
We could:
- wait for hatch to support it, and help if possible
- consider migrating from
hatch to uv
- downside1 : hatch-openzim plugin will not work anymore ... but could probably easily be adapted for uv +
- downside2: uv uses its own "proprietary" lock file, which is not really future-proof)
I would clearly prefer to wait for hatch support (and contribute to it as much as possible).
WDYT?
In many projects we are building (scrapers, zimfarm, ... all besides libraries like python-scraperlib), we use pinned dependencies versions to ensure reproducible builds.
But now the ecosystem has changed and
pylock.tomlformat has landed (see https://packaging.python.org/en/latest/specifications/pylock-toml/)This file would allow to specify range of versions in
pyproject.tomlfor all projects, and use thepylock.tomlto have reproducible builds.This would allow to simplify significantly dependency upgrades since one will just have to update the
pylock.tomlto most recent version matchingpyproject.tomlranges. This is currently done manually and is quite a pain.Currently, hatch does not support this
pylock.tomlfile, see e.g. pypa/hatch#749We could:
hatchtouvI would clearly prefer to wait for hatch support (and contribute to it as much as possible).
WDYT?