[bdice]

Installs the latest RAPIDS nightly wheels together with the newest PyTorch wheel (CUDA 12 stable, CUDA 13 stable, CUDA 13 nightly), then runs import smoke tests and checks torch.cuda.is_available().

Pins added to ci/pytorch/constraints.txt are applied to the install, so a proposed dependency change (e.g. cuda-bindings>=12.9.6) can be checked against PyTorch by editing that file in a PR. The job runs on PRs but is not required by pr-builder.

Part of #794.

[jameslamb]

Nice, this is the type of thing I was envisioning and I think it'll help a lot!

But leaving a blocking review because I think that without explicit tests of "latest RAPIDS is installable with oldest torch" it's not meeting the main goal from our discussion.

[jameslamb]

Suggested change

--extra-index-url "${TORCH_INDEX_URL}" \

We downloaded the torch wheel we need, should not need to consider the torch index any more.

[bdice]

Kept this one: nightly torch pins triton==3.9.0+git<sha>, which is only published on the PyTorch nightly index (PyPI has no triton 3.9.0), so dropping it breaks the nightly/cu130 job. The downloaded-wheel path still prevents falling back to a different torch. Added a comment explaining why the index stays.

[jameslamb]

Ah, ok that's fine.

[jameslamb]

I'm not sure where to fit it in the implementation here but... somewhere, we want to test "oldest-supported stable PyTorch" too.

I don't think this job as written would have caught that it's too soon to update our cuda-core floor (ref: NVIDIA/cuda-python#1915 (comment))

Today I think that's something like the following for all of RAPIDS (narrower environments can be compatible with older versions):

# CUDA 12:
https://download.pytorch.org/whl/cu129 'torch==2.9.1+cu129'

# CUDA 13:
https://download.pytorch.org/whl/cu130 'torch==2.10.0+cu130'

It'd be really helpful to cover those so we know when we break compatibility with them and can make that an intentional choice.

Maybe an optional TORCH_CONSTRAINT that gets appended to the pip download torch?

Like:

          - CUDA_VER: "12.2.2"
            TORCH_INDEX: "nightly/cu129"
            TORCH_CONSTRAINT: "<2.10"

[bdice]

Added --torch-constraint and two oldest-torch entries:

• CUDA 12: cu129, torch==2.9.1
• CUDA 13: cu130, torch==2.13.0

For CUDA 13 I used 2.13.0 rather than 2.10.0 because latest RAPIDS is already uninstallable with torch 2.10–2.12: those pin nvjitlink to 13.0.x (nvidia-nvjitlink==13.0.88 / cuda-toolkit[nvjitlink]==13.0.2), while current cuml-cu13 nightlies require nvidia-nvjitlink>=13.3. Verified with a resolve against the nightly + PyTorch indexes; 2.13.0 is the oldest cu130 torch that resolves today.

If that break was unintentional, we can relax the floor in cuml and move this pin back to ==2.10.0.

[jameslamb]

ohhhhhhhhhh right right right, I was thinking about this from back when we were intentionally building our -cu13 wheels with CTK 13.0.

Yes that's right, for CUDA 13 the floor is 2.13.0 because that was the first torch version that got the looser nvJitLink pins.

[jameslamb]

Approving the general shape of this, so you have what you need to merge. You and your agent can fix the bash syntax issue. Please do double-check the logs to be sure we're getting the torch versions we're expecting.

[jameslamb]

This is really over-specific... it'll miss other operating systems or Python versions and we probably wouldn't catch needing to update this.

I think it'd be safe to unconditionally replace citestwheel:[0-9][0-9]\.[0-9][0-9]- with citestwheel:{NEXT_SHORT_TAG}-.

[bdice]

Agreed. I tried to think of a good way to make the pinning itself OS/Python agnostic but "26.12-latest" won't be a good fit because we need this to vary by CUDA version.

It's fixed now.

[bdice]

/merge