Repository navigation
refactor(toolchain): select bundled coverage wheels with select_whl - #4414
Merged
rickeylev merged 5 commits intoNov 8, 2026
Merged
Conversation
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
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.
This was referenced Nov 7, 2026
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.
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
approved these changes
Nov 8, 2026
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:...")- andthe Starlark side uses
select_whlto pick the wheel that is compatible withthe 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.:
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-anywheel of coverage 7.17.0 instead of7.10.7.
This prepares for selecting the platform specific wheels for more of the
toolchain platforms.
Work towards #3902