Skip to content

refactor(toolchain): select bundled coverage wheels with select_whl - #4414

Merged
rickeylev merged 5 commits into
bazel-contrib:mainfrom
aignas:aignas.refactor.coverage-select-whl
Nov 8, 2026
Merged

rickeylev merged 5 commits into
bazel-contrib:mainfrom
aignas:aignas.refactor.coverage-select-whl

Conversation

@aignas

@aignas aignas commented Nov 7, 2026 •

Copy link
Copy Markdown
Collaborator

refactor(toolchain): select bundled coverage wheels with select_whl

Before this change the coverage wheels bundled with the hermetic toolchain
were stored as a nested dict keyed by the python ABI and the toolchain
platform, and the platform filtering was done in the Python update script.

Now the update script stores all of the wheels as a flat list using a
format similar to uv.lock - struct(url = ..., hash = "sha256:...") - and
the Starlark side uses select_whl to pick the wheel that is compatible with
the python version and the toolchain platform. The update script no longer
does any filtering, but it accepts multiple coverage versions, each with an
optional PEP 508 marker for when it should be used, because newer coverage
releases drop support for older python versions, e.g.:

bazel run //dev/update_deps:update_coverage_deps -- \
    "7.10.7; python_full_version < '3.15'" \
    "7.17.0; python_full_version >= '3.15'"

The marker is stored on each wheel and is evaluated against the python
version of the toolchain before selecting the wheel.

The wheel that is selected for each toolchain is unchanged, except for the
python 3.15+ toolchains on the platforms without a platform specific wheel,
which now fall back to the py3-none-any wheel of coverage 7.17.0 instead of
7.10.7.

This prepares for selecting the platform specific wheels for more of the
toolchain platforms.

Work towards #3902

Before this change the coverage wheels bundled with the hermetic toolchain
were stored as a nested dict keyed by the python ABI and the toolchain
platform, and the platform filtering was done in the Python update script.

Now the update script stores the wheels as a flat list using a format
similar to `uv.lock` - `struct(url = ..., hash = "sha256:...")` - and the
Starlark side uses `select_whl` to pick the wheel that is compatible with
the python version and the toolchain platform. The update script no longer
filters by platform, but it accepts multiple coverage versions, each with a
range of python versions to take the wheels for, because newer coverage
releases drop support for older python versions, e.g.:

```
bazel run //dev/update_deps:update_coverage_deps -- 7.10.7:cp39-cp314 7.17.0:cp315
```

The wheel that is selected for each toolchain is unchanged and the
unsupported toolchain platforms still fall back to the `py3-none-any` wheel.

This prepares for selecting the platform specific wheels for more of the
toolchain platforms.

Work towards bazel-contrib#3902
@aignas
aignas requested a review from rickeylev as a code owner November 7, 2026 04:56
@aignas

aignas commented Nov 7, 2026

Copy link
Copy Markdown
Collaborator Author

This PR was written by an AI coding agent (Claude Code) under the direction of @aignas, who is responsible for the change and reviews it before merge (semi-autonomous). The agent monitors CI and pushes fixes for CI failures; review comments are handled by the human author, who may use the agent to prepare follow-up changes.

This is an agent-generated comment, posted at the request of the PR author.

…ions

Instead of a python tag range for each coverage version, use PEP 508
markers on the wheels to express which coverage version is for which
python versions.
@aignas

aignas commented Nov 7, 2026

Copy link
Copy Markdown
Collaborator Author

PTAL

… versions

Use the same form of the markers that uv writes in the uv.lock files.
Always render the marker with json.dumps so that the Starlark code can use
direct attribute access, and derive the sort key from the URL instead of
storing the filename.
Use direct attribute access for the marker, drop the unreachable hash
algorithm check and update the stale comment about the extracted wheel.
@rickeylev

Copy link
Copy Markdown
Collaborator

The coverage libs are another thing we should give "provide by default but use user deps is available" treatment to, like we were talking about doing with pip and twine. Something for another PR though

bot review incoming

@rickeylev
rickeylev added this pull request to the merge queue Nov 8, 2026
Merged via the queue into bazel-contrib:main with commit d6cb450 Nov 8, 2026
13 checks passed
@aignas

aignas commented Nov 8, 2026

Copy link
Copy Markdown
Collaborator Author

I rescoped the attached issue to be about that and I have a good idea how we could do it.

aignas added a commit to aignas/rules_python that referenced this pull request Nov 9, 2026
…atforms

Before this change the bundled coverage wheels were only selected for the
glibc `x86_64` and `aarch64` Linux and the macOS toolchains. All of the other
toolchain platforms fell back to the pure Python `py3-none-any` wheel, which
lacks the C tracer and is slower.

This adds `python_toolchain_platform`, which creates the `select_whl` target
platform (the PEP 508 env and the whl ABI and platform tags) from the python
version and the python toolchain platform, e.g.
`x86_64-unknown-linux-musl` or `aarch64-apple-darwin-freethreaded`. The
coverage wheel selection now uses it, so the musl `x86_64`, `i386`,
`ppc64le` (Python 3.15) and `riscv64` Linux toolchains get the platform
specific wheels. The selected wheels for the other toolchains are unchanged.

* Also updates the coverage docs, which said that the platforms without a
  bundled wheel get no coverage tool.

Stacked on bazel-contrib#4414.

Work towards bazel-contrib#3902
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants