Build against NumPy 2.x and harden the meson/CI build

[brmather]

Summary

PyPI's latest wheels (2.3.3) are compiled against NumPy 1.x and crash at import under NumPy 2.x (A module that was compiled using NumPy 1.x cannot be run in NumPy 2.0). This PR builds stripy against NumPy 2.x — which produces binaries that run on both 1.x and 2.x — and fixes the chain of related blockers that were preventing a working 2.3.4 wheel from ever reaching PyPI, plus several build/CI robustness issues.

Addresses #114 and #115 · Closes #117 · Refs #116

What's in here

NumPy 2.x (the core fix)

• pyproject.toml: build-requires numpy>=2.0; runtime relaxed to numpy>=1.19.3 (the 2.0 back-compat floor) so 1.x environments still work; added py3.13; dropped the dead [tool.setuptools] block.
• Replaced NumPy aliases removed in 1.24 (np.int, np.bool) that crashed at runtime under NumPy 2.x.
• Removed the obsolete numpy.distutils setup.py/setup.cfg (dead under the meson-python backend) and the now-broken in-repo conda/ recipe (superseded by the conda-forge feedstock).

Release/CI pipeline

• pypi.yml: fixed the actions/upload-artifact@v4 duplicate-name failure — all matrix jobs uploaded under the same name, which fails the run; now unique per-job names + download-artifact … pattern/merge-multiple. Bumped actions, cibuildwheel → 2.21.3 (cp313), added scipy to the wheel test deps. macos-14 (arm64) was already added, so releases now ship Apple-silicon wheels.
• CI.yml: fixed a latent bug where pytest ran from the repo root and imported the ./stripy source (no .so) instead of the installed package → now runs from a neutral dir. Added a py3.9–3.13 × numpy{<2, ≥2} matrix that exercises exactly the "numpy-2-built wheel on numpy 1.x" path.
• Modernised the doc workflows and the Fortran-setup composite action.

meson robustness

• meson.build: removed the fragile os.chdir("..") numpy-include hack; fixed malformed rpath link args; excluded editor cruft from install_subdir.
• Build issue with flang 21 #116: the per-platform link flags (-static, -Wl,-rpath) are gfortran/GCC conventions — now gated on meson.get_compiler('fortran').get_id() == 'gcc' so LLVM flang / MSVC toolchains don't get bogus flags. Because both host_machine.system() and get_compiler('fortran') resolve to the host/target, cross-compiled gfortran builds (conda-forge linux-aarch64/osx-arm64) still get the correct flags. (Note: this removes stripy's contribution to the Build issue with flang 21 #116 log; the fatal flang_rt.runtime.dynamic.lib error there is a flang-21 toolchain issue on the feedstock side, not stripy.)

#117 — the ier=-2 error message described only one of the two collinear cases the Fortran can return (first-three-nodes-collinear vs. a later ADDNOD collinearity). Extended the message in both spherical.py and cartesian.py (verified against stripack.f90/tripack.f90).

Hygiene — widened .gitignore (f2py output + local data caches), removed stray build artifacts and dead conda-CI env files, refreshed the README workflow badges/conda channel, added a Changelog entry.

Validation

Built locally in a clean venv (pip install ., PEP 517 isolation → compiled against numpy 2.5.1) and ran the suite under numpy 2.5.1:

46 passed, 2 warnings

All five compiled extensions import, and both test_linear_interpolation variants pass — the failure tracked in #115. A separate clean no-cache rebuild confirmed the meson #116 change compiles and links on the gfortran path with no behaviour change.

Not included / follow-ups

• Publishing to PyPI still requires cutting a v2.3.4 GitHub release — that's what triggers the (now-fixed) wheel upload.
• The conda-forge feedstock is intentionally untouched: the autotick bot opens the version-bump PR automatically once the PyPI sdist exists (the new sha256 can't be computed before then).
• Pre-existing, out of scope: the permute retry loop in spherical.py (_update_triangulation) raises even if the final attempt succeeds (if niter >= 5 should be if ierr == -2). Happy to fix in a follow-up.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FFBEqxMhk9Ut6vVm5jfV8d

---

Update — CI is green; wheel-coverage changes to note

The first real CI runs (the old workflows were effectively not running tests — pytest ran from the repo root and imported the un-built source tree) surfaced several issues, now fixed on this branch:

• test_linear_interpolation used exact float == on interpolated endpoints — platform-dependent for the permuted mesh (failed on Linux x64, passed on macOS arm64). Now np.isclose (fixes test_linear_interpolation is failing for NumPy 2.x #115).
• macOS wheels: set MACOSX_DEPLOYMENT_TARGET per runner so delocate accepts the bundled Homebrew libgfortran.
• Linux wheels: PIP_ONLY_BINARY=scipy (stop source-building scipy in the container) and build on manylinux_2_28 (GCC 12) — the old manylinux2014 image couldn't build modern numpy/scipy from source (NumPy requires GCC >= 10.3).
• Added concurrency (cancel superseded runs) and stopped feature-branch pushes from redundantly building the full wheel matrix.
• Trimmed the test matrix (9 → 3 jobs): kept the unique numpy-1.x ABI path (py3.9/3.12) plus one numpy-2.x smoke test (py3.13); the numpy-2.x-across-all-pythons grid was already covered by the per-OS wheel tests.

Wheel platform coverage changed — please note for the release:

• macOS: Apple-silicon (arm64) only, minimum macOS 14. No Intel-mac (x86_64) PyPI wheel — Intel users are served by the conda-forge package. A portable low-target gfortran could restore lower/Intel targets later.
• Linux: glibc ≥ 2.28 (manylinux_2_28; RHEL8 / Ubuntu 18.10+), up from the old manylinux2014 (glibc 2.17) baseline.

All checks green: 3 test jobs + sdist + ubuntu / windows / macos-14 wheels.

[brmather]

Overhaul the rusty CI matrix, now we're getting green ticks...

[brmather]

@lmoresi - if you're happy with this, then I'll merge and create a v2.4 release.