Skip to content

Support patch-level Python versions #1371

Closed
@rickeylev

Description

@rickeylev

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions