Leo Fang

> I think we can just add `CUPY_CACHE_KEY` to `compile_time_env` and embed it to some Cython module (e.g. `cupy/_core/core.pyx`). Good idea, and I think we've done that! 🙂 https://github.com/cupy/cupy/blob/9506efc49080c76a9662485e20cf7d95cd03394c/cupy/cuda/jitify.pyx#L38 Would...

Turns out this > We can generate a hash at build time by extending the current `CUPY_CACHE_KEY` coverage to also cover the CCCL headers is already done, because CCCL headers...

For concrete code that can be compiled standalone by either NVRTC or NVCC and therefore can be encapsulated into a single .cu file, I prefer to just use `RawModule`'s `path`...

Very unlikely. We use NumPy heavily in cuda-core (and nvmath-python and the upstream Numba): https://github.com/search?q=repo%3ANVIDIA%2Fcuda-python+numpy+path%3Acuda_core%2Fcuda&type=code Without assuming NumPy exists it is really challenging to write interoperable code. We'd end up...

FWIW we don't even set a version constraint on NumPy as suggested by NEP 29/Spec 0, only that it exists in the user env: https://github.com/NVIDIA/cuda-python/blob/f903d98bb57f628533de392b745dc94b3e27dc3c/cuda_core/pyproject.toml#L45-L47, so this is pretty relaxing.

Unless there is a compelling reason let's close this for now.

btw I haven't measured for CuPy, but for `cuda.bindings` I see 2x increase in the build time with Cython 3.1.0. Something to watch out for... https://github.com/NVIDIA/cuda-python/issues/642

btw Array API (#4789) also requires typed APIs, but since it's contained in a standalone namespace, it's much easier to address than CuPy itself.

Indeed, it'd be better that this effort starts with SciPy then propagates to CuPy, not the other way around. Also it'd be nice to cross-reference the efforts in different projects;...

cc @eriknw for vis