Add CuPy

[leofang]

As encouraged by @betatim and discussed in the PFN-NV CuPy team sync w/ @kmaehashi (xref cupy/cupy#9974), we would like to ship CuPy nightly wheels (cupy-cuda12x and cupy-cuda13x). Please let us know how to proceed 🙂 Example wheels can be downloaded from this draft PR: cupy/cupy#10049.

[betatim]

I'd be 👍 on this. Let's see what other people think.

Usually @matthewfeickert runs the process (regarding next steps).

[tupui]

Also +1 there.

[agriyakhetarpal]

I'm not really part of the SP tools team per se, but I wanted to know if there are any concerns about the wheel sizes to take note of (though not immediately, but for later – see below)? I ask because the CUDA 12.9.2 wheels per Python version on Linux are ~129 MiB each, and on Windows, they are ~95 MiB each. The CUDA 13 wheels on Linux are 69 MiB, and the Windows counterparts are ~35 MiB.

Assuming that a newer set of wheels overwrites the previous set upon each upload and, say, only 3.14 and 3.14t are uploaded to start with, that would translate to (68 + 128.1 + 35.1 + 95.3 = 326.5 MiB) for 3.14, and (67.9 + 128.0 + 35.9 + 96.2 = 328 MiB), i.e., a total of 654.5 MiB.

---

Currently, we are using 22.9 GiB of the 40 we have, and PyArrow is the largest consumer at 9.0 GiB (217 files and nearly 40% of all used space). Output from a quickly vibe-coded script that iterated through the index:

Metric	Value
Total packages	35
Total files	2,081
Total size	~22.9 GiB
Quota remaining	~17.1 GiB

The biggest consumers by far are:

Package	Space
pyarrow	9.0 GiB (217 files)
pandas	2.5 GiB (246 files)
statsmodels	2.2 GiB (186 files)
scipy	2.3 GiB (80 files)
matplotlib	1.1 GiB (117 files)
pillow	1.1 GiB (197 files)

24 CuPy wheels from the CI job would add 1,855 MiB (~1.81 GiB), bringing the space used to 24.7 GiB, which is 61.7% of the 40 GiB quota. So while there's still headroom, I thought it would be useful to raise that this may not be the case for long, and that it would increase if the wheels are not overwritten! 😅

[betatim]

Thanks for thinking of disk space usage and putting in the (vibe) effort to check.

I think for a nightly to be useful you probably need more than just the latest one, maybe "a few" is the right number. I can't fully explain why I think this, but it just seems right to not only have one nightly version of a package. Imagine you were testing something with a nightly version, the discussion takes a day or two (eg timezones, holiday, etc) and now no one can reproduce your run anymore because the nightly has been deleted.

However I think it would be fine to only upload a nightly every few nights (say every second night).

So we probably need space for ~5-6 versions?

Overall I am still in favour, but I think we need to figure something out. Even if that is a "let's do X now and review in a few months"

[betatim]

And for context (I should have gone looking for this first...) https://github.com/scientific-python/upload-nightly-action#artifact-cleanup-policy-at-the-scientific-python-nightly-wheels-channel

So we already have a clean up policy (nothing to decide here). We keep the last five uploads, which matches my guesstimate in my previous comment (spooky!). I think this means cupy can decide how they want to use those "last five" versions (every night, every second, etc).

As a guiding principle the total space consumed by cupy should not be an outlier (like pyarrow).

[leofang]

Thanks guys! For a more accurate estimate: We plan to generate 3 OSs (linux-64, linux-arm64, win-64) x 6 Python versions x 2 CUDA versions per night, so it'd be about ~3 GB give or take.

We have a plan to aggressively shrink the binary size down to ~20% or even lower (cupy/cupy#9238), so ~0.6 GB/night, but it is still WIP.

In any case, our nightly wheels will also be downloadable from GitHub, similar to what we do in other CUDA Python projects (example). It's the same CI design.

[stefanv]

I think Anaconda will increase our storage if requested; we owe them a blog post about how we use their infrastructure and why it is useful to the community, which we should write & share before making that request :)

For now, I don't think we need to fret about storage too much.

[matthewfeickert]

Usually @matthewfeickert runs the process (regarding next steps).

Sorry for the delay. I am super underwater this week, so in general anyone in the Scientific Python organization should feel free to jump in if I'm not responsive in under a day. 🙇

@leofang Please have a member of the CuPy team complete the missing items from the checklist to get started.

• Create an account on Anaconda Cloud
• Reply here with the link to your account
• Make a new Anaconda Cloud API token with permissions described in https://scientific-python.org/specs/spec-0004/#process-for-adding-new-projects

• Save the API token as a repo GitHub Actions secret named ANACONDA_ORG_UPLOAD_TOKEN
• Direct @scientific-python/nightly-wheels-developers to a cupy nightly wheel for us to upload to create the package in the registry
  • c.f. CI: build cupy-cuda{12,13}x wheels on GH-hosted runners (#9794, #9974) cupy/cupy#10049
• Verify that we have added you to the cupy team "Group" on https://anaconda.org/scientific-python-nightly-wheels
• Verify that we have added the package scientific-python-nightly-wheels/cupy-cuda*x to the cupy team "Group"

If you'd also like to use the scientific/upload-nightly-action GitHub Action please check out the action repo's README. If you need to collect wheels from different CI jobs, consider creating a new GitHub Actions workflow with logic similar to matplotlib's or Awkward's.

If you have any questions please just ask here!

For now, I don't think we need to fret about storage too much.

Agreed for all the reasons given. Thank you @agriyakhetarpal and @leofang for being conscientious and thinking about this though!

we owe them a blog post about how we use their infrastructure and why it is useful to the community, which we should write & share before making that request :)

@stefanv Sounds like a good SciPy 2026 Sprints activity if you want to tag team that with me. 🙂