Description
The basic feature request is to allow patch-level specificity of Python versions e.g. python.toolchain(python_version="3.1.2")
.
Supporting this allows builds to be a bit more reproducible, as it removes the variability of different rules_python versions selecting a different patch level. That said, it's also rather niche. Patch level differences are usually inconsequential.
aignas@ also points out:
different Python toolchain versions come from different indygreg toolchain releases and some of them may have different packaging behaviour, like the last release contains the following changelog: <various updates to pip, musl, openssl, sqlite, libxzma, etc>
Making this work cleanly requires addressing a few things, though:
- If two modules (or configs) specify different patch levels, what happens?
- Toolchain repositories are named e.g. python_X_Y; these names aren't supposed to be public, but usage of them is fairly common.
- Version-pinning rules generate
//X.Y:defs.bzl
files. - PyPI repo names contain the X.Y version, e.g.
pip_38_foo
. - Does the packaging ecosystem support patch-level specificity? e.g. pip resolution, environment markers, whl naming formats, etc.
cc @aignas
Few potential ideas:
- Allow the root module to specify patch-level version. It has precedence. This allows
projects to pin to specific versions if they want to. Submodules are not allowed to use patch-level specificity; not sure whether to silently ignore, ignore with warning, or error.