I think the use of requirements files with X.Y.Z pinned version constraints is good but not enough to ensure full reproducibility of the builds (there can be .post0 markers after the .Z component for instance). I think we should use an explicit lock file to manage:
The lockfile(s) should be automatically refreshed, e.g. on a monthly basis with a relative dependency cooldown policy of a week to reduce the exposure of the release process to ongoing OSS Supply Chain attacks.
The lockfile(s) in the release repo could either be managed via uv or pixi. I don't think it matters much because we don't need conda-forge for the build and testing process in this repo. All the Python-level builds dependencies are fetched from pypi.org and the rest come from the system image (e.g. manylinux). EDIT: actually we do fetch a fixed binary for libomp on macOS, so maybe we could use pixi and a lock file to do that more automatically.
When the lock files are updated, we should use relative dependency cooldowns such as uv's exclude-newer config or pixi's exlude-newer config).
Ideally, the build dependencies should also be locked explicitly in the repo as for the other dependencies. According to cibuildwheel's doc, the pip wheel command is used under the hood to setup the build env automatically. By default, it will install dependencies from the pyproject.toml file. However, it should be possible to pass an explicit pylock.toml export of a proper uv managed lockfile to pip wheel -r. Alternatively, we configure cibuildwheel's before-build hook to run a script to explicitly prepare the build environment manually using uv or pixi commands and disable build isolation and run pip wheel --no-build-isolation --no-deps.
I think the use of requirements files with X.Y.Z pinned version constraints is good but not enough to ensure full reproducibility of the builds (there can be
.post0markers after the.Zcomponent for instance). I think we should use an explicit lock file to manage:The lockfile(s) should be automatically refreshed, e.g. on a monthly basis with a relative dependency cooldown policy of a week to reduce the exposure of the release process to ongoing OSS Supply Chain attacks.
The lockfile(s) in the release repo could either be managed via
uvorpixi. I don't think it matters much because we don't need conda-forge for the build and testing process in this repo. All the Python-level builds dependencies are fetched from pypi.org and the rest come from the system image (e.g. manylinux). EDIT: actually we do fetch a fixed binary for libomp on macOS, so maybe we could use pixi and a lock file to do that more automatically.When the lock files are updated, we should use relative dependency cooldowns such as uv's
exclude-newerconfig or pixi'sexlude-newerconfig).Ideally, the build dependencies should also be locked explicitly in the repo as for the other dependencies. According to cibuildwheel's doc, the
pip wheelcommand is used under the hood to setup the build env automatically. By default, it will install dependencies from thepyproject.tomlfile. However, it should be possible to pass an explicitpylock.tomlexport of a proper uv managed lockfile topip wheel -r. Alternatively, we configurecibuildwheel'sbefore-buildhook to run a script to explicitly prepare the build environment manually usinguvorpixicommands and disable build isolation and runpip wheel --no-build-isolation --no-deps.