You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
.github/renovate.json5 freezes numpy / pandas / pyarrow because they sit on the Arrow IPC data path and must move in lockstep. Nothing freezes the CI interpreter those wheels are selected for, so Renovate raised actions/setup-python's python-version: to 3.14 in #7715 and build / amber-integration broke on both runners.
The interpreter is downstream of the frozen pins — a Python version is only usable if the pinned packages publish a wheel for it:
Pin in amber/requirements.txt
Wheels published
cp314?
numpy==2.1.0
cp310–cp313
no
pandas==2.2.3
cp310–cp313
no
pyarrow==23.0.1
cp310–cp314
yes
With no cp314 wheel, uv falls back to a source build of numpy, which does not compile against the 3.14 headers.
Before: Renovate bumps python-version -> 3.14 -> no numpy cp314 wheel
-> uv source-builds numpy -> 11 compile errors -> job fails
After: python-version frozen with the numpy/pandas pins
-> prebuilt wheel resolves -> job installs as before
Renovate rewrites three standalone python-version: inputs:
Site
Job
Value on main
build.yml:401
amber-integration
3.11
build.yml:127
frontend
3.12
benchmarks.yml:217
Bench
3.12
The pyamber matrix at build.yml:1041 is ["3.11", "3.12", "3.13"] — a plain list Renovate never reads. So besides breaking the build, the bump silently splits the interpreter CI actually runs on from the matrix that is actually tested.
Building pandas==2.2.3
Building numpy==2.1.0
× Failed to build `numpy==2.1.0`
├─▶ The build backend returned an error
╰─▶ Call to `mesonpy.build_wheel` failed (exit status: 1)
../numpy/_core/src/umath/string_fastsearch.h:132:5: error: no type named
'ptrdiff_t'in namespace 'std'; did you mean simply 'ptrdiff_t'?
132 | std::ptrdiff_t
| ^~~~~~~~~~~~~~
...
11 errors generated.
[253/324] Compiling C++ object
numpy/_core/_multiarray_umath.cpython-314-darwin.so.p/src_umath_special_integer_comparisons.cpp.o
ninja: build stopped: subcommand failed.
##[error]Process completed with exit code 1.
What happened?
.github/renovate.json5freezesnumpy/pandas/pyarrowbecause they sit on the Arrow IPC data path and must move in lockstep. Nothing freezes the CI interpreter those wheels are selected for, so Renovate raisedactions/setup-python'spython-version:to 3.14 in #7715 andbuild / amber-integrationbroke on both runners.The interpreter is downstream of the frozen pins — a Python version is only usable if the pinned packages publish a wheel for it:
amber/requirements.txtnumpy==2.1.0pandas==2.2.3pyarrow==23.0.1With no cp314 wheel,
uvfalls back to a source build of numpy, which does not compile against the 3.14 headers.Renovate rewrites three standalone
python-version:inputs:mainbuild.yml:401amber-integrationbuild.yml:127frontendbenchmarks.yml:217BenchThe pyamber matrix at
build.yml:1041is["3.11", "3.12", "3.13"]— a plain list Renovate never reads. So besides breaking the build, the bump silently splits the interpreter CI actually runs on from the matrix that is actually tested.How to reproduce?
github-actionsgroup PR that carries thepythonuses-withbump — chore(deps, ci): update github-actions #7715.build / amber-integration (ubuntu-latest, 17)and(macos-latest, 17)fail at the Install Python dependencies step.Locally, on a 3.14 interpreter:
Wheel availability can be confirmed straight from PyPI:
Version/Branch
1.3.0-incubating-SNAPSHOT (main)
Commit Hash (Optional)
2f7e75e (head of #7715)
Relevant log output