Skip to content

Constrain build-time numpy version to fix CI hash-mismatch and Python-version conflicts - #9436

Merged
alexreinking merged 2 commits into
mainfrom
fix-linux32-numpy-build-hash-mismatch
Sep 10, 2026
Merged

alexreinking merged 2 commits into
mainfrom
fix-linux32-numpy-build-hash-mismatch

Conversation

@alexreinking

@alexreinking alexreinking commented Sep 10, 2026

Copy link
Copy Markdown
Member

Summary

linux-32 CI (ci-llvm-main/22/21) started failing with a uv sync error:

Failed to download and build `ml-dtypes==0.5.4`
  Failed to install requirements from `build-system.requires`
  Failed to download and build `numpy==2.4.6`
    Hash mismatch for `numpy==2.4.6`

Root cause: numpy==2.4.6 (and 2.5.2) only have piwheels ARM wheels recorded in uv.lock (they're only needed there via platform_machine == 'armv7l'/'armv8l' markers). Since uv 0.12.11 (changelog: "Verify source archives against hashes recorded in uv.lock before reading their metadata or running their build backends"), when uv resolves ml-dtypes's build-time numpy requirement 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.lock itself hadn't changed since #9272 (2026-08-24) until this PR — bisecting merged PRs shows this passed through uv 0.12.10 (2026-09-07) and started failing under uv 0.12.12 (2026-09-10), bracketing the regression to uv 0.12.11.

Rather than pin the uv version (which would require every contributor to carefully track a specific uv release), this adds a build-constraint-dependencies entry 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:

  • The first attempt used an exact numpy==2.4.2 constraint. That fixed linux-32 but broke windows-32, since that job runs Python 3.10.20 and numpy==2.4.2 requires Python>=3.11 — the exact pin made ml-dtypes's build-time numpy requirement unsatisfiable there.
  • The current version excludes just the two problematic versions instead, so uv falls back to whichever already fully-locked numpy version applies for the current Python version (2.2.6 for Python<3.11, 2.4.2 for Python>=3.11) on every affected platform, rather than forcing one specific version everywhere.

Test plan

  • uv lock regenerates uv.lock deterministically with the new build-constraints entries (confirmed identical output when relocked under uv 0.12.5, 0.12.9, and 0.12.12)
  • pre-commit run uv-lock passes
  • uv sync --frozen --group ci-base --no-install-workspace --python 3.10 locally resolves numpy==2.2.6
  • uv sync --frozen --group ci-llvm-main --no-install-workspace --python 3.11 and --python 3.13 locally resolve numpy==2.4.2
  • CI green on linux-32 and windows-32 for ci-llvm-main/22/21 (can't reproduce the i686/win32 sdist-build paths locally on macOS/ARM to verify directly)

🤖 Generated with Claude Code

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>
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>
@alexreinking alexreinking changed the title Constrain build-time numpy to 2.4.2 to fix linux-32 CI hash mismatch Constrain build-time numpy version to fix CI hash-mismatch and Python-version conflicts Sep 10, 2026
@codecov

codecov Bot commented Sep 10, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 69.89%. Comparing base (a95f4de) to head (00e4dd1).

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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@alexreinking
alexreinking merged commit 127fd5e into main Sep 10, 2026
23 of 24 checks passed
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.

3 participants