Add CUDA 12.5 to conda nightlys in the selector

[jarmak-nv]

Small PR that adds CUDA 12.5 to the conda nightlys.

When 24.08 releases a followup PR will be made that:

1. Sets 12.5 as the default
2. Removes 12.2 as an option (still supported but not necessary for the selector)

[netlify]

✅ Deploy Preview for docs-rapids-ai ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	d13a9b4
🔍 Latest deploy log	https://app.netlify.com/sites/docs-rapids-ai/deploys/669823cf81e4c700082e7f7f
😎 Deploy Preview	https://deploy-preview-522--docs-rapids-ai.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[jakirkham]

xref: rapidsai/build-planning#73

[bdice]

This looks fine. We may be able to remove CUDA 11.2 from the selector, so that we don’t list 5 versions. conda-forge has moved entirely to building with 11.8, and we no longer test 11.2 in our CI workflows.

[jarmak-nv]

This looks fine. We may be able to remove CUDA 11.2 from the selector, so that we don’t list 5 versions. conda-forge has moved entirely to building with 11.8, and we no longer test 11.2 in our CI workflows.

With this info, I'm in favor of removing 11.2 here and potentially doing an RSN to drop support altogether.

Also curious if there's a benefit to having 12.0 here. My preference is that the selector helps get people on our recommended versions, so 12.latest if on 12 and 11.8 if on 11. But, not sure if that would cause problems for tensorflow or pytorch.

[bdice]

My preference is that the selector helps get people on our recommended versions

I like that. I would envision this:

• conda shows “CUDA 11” or “CUDA 12”, which then fill out cuda-version=11.* or cuda-version=12.*
• pip shows “CUDA 11” or “CUDA 12”, which resolves to the proper major suffix
• Docker shows each CUDA version for which we produce containers

How would that sound?

[bdice]

cc: @sisodia1701 @raydouglass @jameslamb @KyleFromNVIDIA if you have thoughts on the discussions above

[jarmak-nv]

My preference is that the selector helps get people on our recommended versions

I like that. I would envision this:

* conda shows “CUDA 11” or “CUDA 12”, which then fill out `cuda-version=11.*` or `cuda-version=12.*`

* pip shows “CUDA 11” or “CUDA 12”, which resolves to the proper major suffix

* Docker shows each CUDA version for which we produce containers

How would that sound?

I love this idea!

In situations like this PR where there's a new nightly-only version of CUDA we can have a temp 3rd button that says something like: "RAPIDS 12.5 Pre-Release". I think that's not right, but something to show that it's upcoming support.

[jakirkham]

Thanks Ben! 🙏

Thinking about the discussion above, what if we converted this to CUDA version ranges?

This might also address some of the confusion raised by others in the past about what CUDA versions we support. Not to mention whether a CUDA version can be found that works with RAPIDS and other 3rd party libraries (like PyTorch)

Showed a small sample of this below. Though there may be other adjustments needed if we pursue this approach

[jakirkham]

Suggested change

	cuda_vers: ["11.2", "11.8", "12.0", "12.2", "12.5"],
	cuda_vers: ["11.4-11.8", "12.0-12.2", "12.0-12.5"],

[bdice]

I like this idea but I don't think we need to have both 12.0-12.2 and 12.0-12.5. We should have only one CUDA 12 range.

Suggested change

	cuda_vers: ["11.2", "11.8", "12.0", "12.2", "12.5"],
	cuda_vers: ["11.4-11.8", "12.0-12.5"],

[jakirkham]

Yeah the only reason there are both now is one range is for nightlies and one is for stable (since the two are handled differently atm). If we did this after the release, we could just have one

[bdice]

@jakirkham @jarmak-nv I propose to merge this as-is, and file a follow-up PR with the changes we are proposing for CUDA version ranges instead of individual minor versions.

[jakirkham]

SGTM

[jakirkham]

Thanks all! 🙏