Skip to content
Latchkey

Python NumPy ABI mismatch "built against different version" in CI

A compiled package (pandas, scipy, a vendored extension) was built against one NumPy C-ABI but resolved a different NumPy at runtime. The version skew makes the binary incompatible and the import fails.

What this error means

An import fails with "A module that was compiled using NumPy 1.x cannot be run in NumPy 2.x" or "numpy.dtype size changed, may indicate binary incompatibility." It is deterministic once the versions are pinned.

python
A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.0.1 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
ImportError: numpy.core.multiarray failed to import

Common causes

NumPy upgraded past what a dependency was built for

A wheel compiled against NumPy 1.x is loaded under NumPy 2.x; the C ABI changed, so the extension is incompatible.

Mixed wheels from different build epochs

Some packages were installed as old wheels and another pulled a newer NumPy, leaving the build/runtime versions inconsistent.

How to fix it

Pin a coherent NumPy across all extensions

  1. Decide on a NumPy major aligned with your compiled deps (1.x or 2.x).
  2. Pin NumPy and reinstall the C-extension packages so they match.
  3. Re-run the import to confirm compatibility.
Terminal
# keep everything on a NumPy 2.x build set
pip install --upgrade "numpy>=2" "pandas>=2.2" "scipy>=1.13"

Rebuild dependents against the installed NumPy

Force a fresh build of the extension packages so they compile against the resolved NumPy.

Terminal
pip install --no-binary=:all: --force-reinstall scipy

How to prevent it

  • Lock NumPy and all compiled dependents together in one lockfile.
  • When upgrading NumPy major versions, bump dependents in the same change.
  • Avoid mixing prebuilt wheels from different NumPy epochs.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →