chore(ci): bump tox == 4.25.0#811
Merged
Merged
Conversation
This job has been failing because `cryptography` no longer publishes a
32-bit Windows wheel for Python 3.9. Pip therefore falls back to
building from the sdist, which uses maturin (Rust/PyO3). On the hosted
windows-latest runner only the x86_64 Rust target is installed, while
the Python 3.9 x86 interpreter reports platform `win32` (i686), so
maturin refuses to use it:
'python.EXE' reports a platform 'win32' (architecture 'i686'),
while the Rust target is 'x86_64'. Skipping.
Couldn't find any python interpreters from '...\python.EXE'.
error: metadata-generation-failed
local: FAIL code 1
The combination is effectively unbuildable on GitHub-hosted runners
without provisioning an i686 Rust toolchain plus a 32-bit OpenSSL on
the runner before each install — too brittle to maintain for a
configuration that upstream `cryptography` no longer supports with
prebuilt wheels. Pinning `cryptography` to an older version would only
delay the same break.
64-bit Windows coverage on Python 3.9 is retained via the existing
`windows-latest, 3.9, x64` cells. If 32-bit Windows coverage is later
required, it should target a Python version for which `cryptography`
still ships a `win32` wheel (currently 3.11+ via abi3).
Follow-up to 3532263. A subsequent CI run failed on `windows-latest, 3.10, x86, accept` with the same root cause as the 3.9 cell: 'python.EXE' reports a platform 'win32' (architecture 'i686'), while the Rust target is 'x86_64'. Skipping. 💥 maturin failed error: metadata-generation-failed accept: FAIL code 1 `cryptography` only publishes a `win32` wheel via abi3 starting at cp311. Every Python below 3.11 on Windows x86 therefore falls back to the Rust/maturin sdist build, which cannot succeed on the hosted runner (x86_64-only Rust target, i686 interpreter, and maturin can't infer the interpreter version from the bare `python.EXE` name). The previous commit dropped only 3.9 because that was the cell shown in the first failing log. With `fail-fast: true` the matrix aborts on the first failure, which is why the 3.10 cell only surfaced once 3.9 was excluded. The same logic applies to 3.8. Drop all three pre-3.11 cells on windows-latest + x86. 3.11+ still gets a `cp311-abi3-win32` wheel from `cryptography`, so those cells remain in the matrix.
The previous commit listed three explicit (os, python, architecture) triples to exclude. Since x86 is already excluded on ubuntu-latest and macos-latest by their own (os, architecture) rules, the os qualifier on these entries is redundant. Replace the triples with (python, architecture) pairs so the policy reads as "no x86 testing for Python below 3.11" — which is the actual rule we care about. cp311-abi3-win32 wheels from `cryptography` cover 3.11+, so those cells remain in the matrix. No change in effective coverage.
Partial revert of 5ec3877. The maturin/cryptography sdist-build issue is Windows-specific (no cp38/cp39/cp310 win32 wheel and an x86_64-only host Rust toolchain). On Linux and macOS x86 — if those cells are ever re-enabled — the package would either use a Linux/macOS wheel or a sdist build that doesn't have this architecture-mismatch failure mode. Re-add `os: windows-latest` to each of the three pre-3.11 x86 excludes so the rule expresses what it actually means. Effective coverage today is unchanged (non-Windows x86 is still excluded by the existing (os, architecture) rules above), but the intent is now correct if those blanket excludes are ever lifted.
A subsequent CI run failed on `windows-latest, 3.11, x86, local` with
the same maturin/architecture-mismatch failure as the pre-3.11 cells:
'python.EXE' reports a platform 'win32' (architecture 'i686'),
while the Rust target is 'x86_64'. Skipping.
Preparing metadata (pyproject.toml) did not run successfully.
local: FAIL code 1
That contradicts the "cp311-abi3-win32 wheels cover 3.11+" reasoning
in 5ec3877 / ae48949. The currently-resolved `cryptography` (49.0.0)
has no `win32` wheel for any CPython version, so every 32-bit Windows
row falls back to the same Rust/maturin sdist build, and they all
fail the same way on GitHub-hosted runners.
Collapse the three (os, python, architecture) excludes into a single
(os: windows-latest, architecture: x86) blanket exclude. Removes x86
from CI on Windows entirely. Non-Windows x86 is still gated by the
existing per-OS excludes above, so net coverage is "no x86 anywhere",
which matches the empirical reality of what can actually be built.
The only path back to x86 Windows coverage would be host-side
toolchain provisioning per cell (i686 Rust target + 32-bit OpenSSL +
maturin interpreter rename), which isn't worth the maintenance cost
for a configuration upstream no longer ships wheels for.
lucasmcdonald3
approved these changes
Jun 25, 2026
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
2 participants
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.
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Check any applicable: