Constrain build-time numpy version to fix CI hash-mismatch and Python-version conflicts - #9436
Merged
Merged
Conversation
On linux-32 (i686), uv's build isolation for ml-dtypes' build-time numpy requirement can pick numpy==2.4.6, whose only locked artifact is a piwheels ARM wheel (armv7l/armv8l-only). Validating an i686 sdist build against that wheel's hash fails. numpy==2.4.2 already has a full sdist and wheel set locked for every platform, so constrain build-time numpy resolution to that version via build-constraint-dependencies. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
alexreinking
requested review from
abadams,
derek-gerstmann,
mcourteaux and
slomp
September 10, 2026 16:10
The previous exact numpy==2.4.2 build constraint broke windows-32 (Python 3.10.20): numpy 2.4.2 requires Python>=3.11, so the constraint made ml-dtypes' build-time numpy requirement unsatisfiable there. Exclude just numpy 2.4.6 and 2.5.2 (the two versions with only piwheels ARM wheels locked) instead, so uv falls back to whichever already fully-locked numpy version applies per Python version: 2.2.6 for Python<3.11, 2.4.2 for Python>=3.11. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
derek-gerstmann
approved these changes
Sep 10, 2026
slomp
approved these changes
Sep 10, 2026
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9436 +/- ##
==========================================
- Coverage 70.07% 69.89% -0.19%
==========================================
Files 261 261
Lines 79462 79462
Branches 19365 19365
==========================================
- Hits 55684 55536 -148
- Misses 17908 17959 +51
- Partials 5870 5967 +97 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This was referenced Sep 11, 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
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.
Summary
linux-32CI (ci-llvm-main/22/21) started failing with auv syncerror:Root cause:
numpy==2.4.6(and2.5.2) only have piwheels ARM wheels recorded inuv.lock(they're only needed there viaplatform_machine == 'armv7l'/'armv8l'markers). Sinceuv 0.12.11(changelog: "Verify source archives against hashes recorded inuv.lockbefore reading their metadata or running their build backends"), whenuvresolvesml-dtypes's build-timenumpyrequirement on a platform with no native numpy wheel (linux-32/i686) and has to build numpy from its PyPI sdist, it validates that sdist against the only hash it has on file for that version — the ARM wheel's — which is a different artifact entirely. Hence the mismatch.This isn't a numpy-side change (2.4.6 has been on PyPI since 2026-05-18, unchanged) and
uv.lockitself hadn't changed since #9272 (2026-08-24) until this PR — bisecting merged PRs shows this passed throughuv 0.12.10(2026-09-07) and started failing underuv 0.12.12(2026-09-10), bracketing the regression touv 0.12.11.Rather than pin the
uvversion (which would require every contributor to carefully track a specificuvrelease), this adds abuild-constraint-dependenciesentry under[tool.uv]excluding just the two ARM-only-locked numpy versions (!=2.4.6,!=2.5.2). This scope grew over the course of the PR:numpy==2.4.2constraint. That fixedlinux-32but brokewindows-32, since that job runs Python 3.10.20 andnumpy==2.4.2requires Python>=3.11 — the exact pin mademl-dtypes's build-timenumpyrequirement unsatisfiable there.uvfalls back to whichever already fully-locked numpy version applies for the current Python version (2.2.6for Python<3.11,2.4.2for Python>=3.11) on every affected platform, rather than forcing one specific version everywhere.Test plan
uv lockregeneratesuv.lockdeterministically with the newbuild-constraintsentries (confirmed identical output when relocked under uv 0.12.5, 0.12.9, and 0.12.12)pre-commit run uv-lockpassesuv sync --frozen --group ci-base --no-install-workspace --python 3.10locally resolvesnumpy==2.2.6uv sync --frozen --group ci-llvm-main --no-install-workspace --python 3.11and--python 3.13locally resolvenumpy==2.4.2linux-32andwindows-32forci-llvm-main/22/21(can't reproduce the i686/win32 sdist-build paths locally on macOS/ARM to verify directly)🤖 Generated with Claude Code