Repository navigation
[DISCUSSION] Consider making cupy>=14 a dependency #85
Description
xref #83 (comment)
Starting cupy 14 wheels, have the option on including a ctk, by installing like cupy-cuda12x[ctk]" or "cupy-cuda13x[ctk]" . This makes cupy installed via pip to not depend on a system cuda toolkit., which happens in several systems.
When we install via conda this is not an issue, as conda includes it already.
cupy-xarray, can't work without cupy, at the moment in main cupy is not a dependency, I wonder if the situation described above, makes it easier to implement a reliable path to workable dependencies.
Activity
ncclementi commentedon Mar 13, 2026
@leofang Maybe you have a suggestion, on how to handle this, for a bit more context the dependency was removed because the different builds, i.e cupy, cupy-cuda12x and cupy-cuda13x.
How do other libraries handle this? See extended discussion in #66 (comment)
weiji14 commentedon May 23, 2026
Proper solution would be to wait for stabilization of wheel variants (PEP 825) and for cupy to support it. See upstream thread at cupy/cupy#9258
Alternative solution I mentioned at #66 (comment) is to wait for PEP 771 – Default Extras to be stabilized, and pick a default cuda version.
These are both part of the WheelNext initiative. Some tools like
uvare now variant-enabled, and one could install from a special index (e.g. https://wheelnext.github.io/variants-index-test/v0.0.3/), but I'm not quite sure how this should be enabled for downstream libraries likecupy-xarrayyet.