PyCUDA 2025.1 fails to build from source with NumPy >= 2.3.0 (removed NPY_FARRAY / NPY_CARRAY macros)

[nikarav]

Describe the bug

PyCUDA 2025.1 cannot be built from source when the build environment resolves to NumPy >= 2.3.0. The C++ compilation fails because src/wrapper/mempool.cpp uses NPY_FARRAY and NPY_CARRAY, legacy macros that were deprecated since NumPy 1.7 and fully removed in NumPy 2.3.0 (Jun 7, 2025).

Since pyproject.toml declares numpy>=1.24 with no upper bound, pip's PEP 517 build isolation pulls the latest NumPy (currently 2.4.2) into the isolated build environment, making pip install pycuda==2025.1 fail for any new source installation on Python >= 3.11.

PyCUDA 2026.1 is unaffected — it builds cleanly against all NumPy versions from 2.2.0 through 2.4.2, confirming the source code was updated to use the modern equivalents.

To Reproduce

1. Use a Python 3.11+ environment
2. Run pip install pycuda==2025.1 --no-cache
3. Build fails with C++ compilation errors in src/wrapper/mempool.cpp

Minimal reproduction:

# Fails — isolated build env pulls latest NumPy (2.4.2)
pip install pycuda==2025.1 --no-cache

# Succeeds — constraining build env to NumPy < 2.3
echo "numpy<2.3" > /tmp/constraints.txt
PIP_CONSTRAINT=/tmp/constraints.txt pip install pycuda==2025.1 --no-cache

# Succeeds — 2026.1 uses modern NumPy API
pip install pycuda==2026.1 --no-cache

Bisect across 15 NumPy versions using PIP_CONSTRAINT to control the isolated build environment:

NumPy	PyCUDA 2025.1	PyCUDA 2026.1
2.2.0 - 2.2.6	✅ Builds	✅ Builds
2.3.0 (breaking point)	❌ Fails	✅ Builds
2.3.1 - 2.4.2	❌ Fails	✅ Builds

Expected behavior

pip install pycuda==2025.1 should either build successfully or fail with a clear dependency resolution error, not with cryptic C++ compilation errors. The pyproject.toml should have an upper bound on NumPy that matches what the source code can actually compile against.

Environment

• OS: Linux x86_64 (Docker, base image pytorch/pytorch:2.5.1-cuda12.1-cudnn9-devel)
• CUDA version: 12.1
• PyCUDA version: 2025.1
• Python version: 3.11.10
• Compiler: g++ (conda compiler_compat)

Additional context

Compilation errors:

src/wrapper/mempool.cpp:205:16: error: 'NPY_FARRAY' was not declared in this scope; did you mean 'NPY_FR_Y'?
src/wrapper/mempool.cpp:207:16: error: 'NPY_CARRAY' was not declared in this scope; did you mean 'NPY_WRAP'?
error: command '/usr/bin/g++' failed with exit code 1

This does not surface on Python 3.10 because NumPy 2.3+ requires Python >= 3.11, so the build env is naturally capped at NumPy 2.2.6 which still has the deprecated macros.

Suggested fix for the 2025.1 release — add an upper bound in pyproject.toml:

requires = ["setuptools", "wheel", "numpy>=1.24,<2.3"]

[inducer]

Thanks for the report. I admit, this is the first time I've received a bug report about a non-current version of any of my software.

Sure, I can ship a 2025.1.1 (or so) that adds the constraint you're asking for.

What I don't know is how to systematically prevent this in the future. I don't particularly want to release software with tight upper bounds on dependencies, because:

• It might still work, who am I to ban it?
• I admit I don't have perfect visibility of all the potential upcoming breakers. Most often dependency breakage gets dealt with through "oh-whoops" releases.
• Even if I did have perfect foresight, maintaining the upper bounds seems... laborious.

If you have recommendations for a more structured (and ideally still cheap, in labor time) process, I'd at least be interested.

[inducer]

https://pypi.org/project/pycuda/2025.1.3/

LMK if that does what you like.

[nikarav]

Hey, thanks for the quick answer and solution. Looks great!

Per my understanding in this scenario numpy is used as a build dependency, reflected by build-system.requires.
According to numpy docs they also mention the following:

When you compile against NumPy, you should add the proper version restrictions to your pyproject.toml (see PEP 517). Since your extension will not be compatible with a new major release of NumPy and may not be compatible with very old versions.

The good thing is that when you build wheels for your package using a NumPy 2.x version at build time, those will work with NumPy 1.xx.

Cheapest Suggestion: Add a weekly cron CI job that builds against the latest numpy (no pin).