Add wheel tests to CI

[gforsyth]

Adding this now that wheels are available

• deps(kvikio): add kvikio to CUDA version matrices
• test(wheels): enable wheel tests in CI

Resolves #1344

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[pentschev]

LGTM, thanks @gforsyth !

[pentschev]

/ok to test

[pentschev]

@gforsyth I've triggered CI manually now but FYI going forward you'll need to setup GitHub commit signing to ensure CI runs automatically.

[pentschev]

We don't currently use tags/keyword in the PR titles, so as a nit I just changed its title to contain only the message, this is really just a nit, hope you don't mind Gil. 🙂

[jameslamb]

Thanks for working on this! Left some suggestions.

Can you please also add a similar entry in https://github.com/rapidsai/dask-cuda/blob/branch-25.02/.github/workflows/test.yaml? You can follow the patterns from other repos, like https://github.com/rapidsai/cudf/blob/branch-25.02/.github/workflows/test.yaml

Those .github/workflows/test.yaml workflow configs define which tests run in 3 scenarios:

• on the target branch (e.g. branch-25.02) after merges
• nightly
  • runs: https://github.com/rapidsai/workflows/actions/workflows/nightly-pipeline.yaml
  • config: https://github.com/rapidsai/workflows/blob/main/.github/workflows/nightly-pipeline.yaml
• manually triggered in the UI via workflow dispatch

@ me if you want some helping resolving the CI failures.

[jameslamb]

oh nice, thank you!

[gforsyth]

Hey @jameslamb -- back to this after a brief interlude.

Could you help me understand the dependency miss in the wheel tests? pip isn't finding the (as yet unpublished) cudf==25.2.*,>=0.0.0a0 -- is there a pre-release staging area that it should be pointing at? Or are there no 25.2.* wheels available for cudf yet?

[jameslamb]

pip isn't finding the (as yet unpublished) cudf==25.2.,>=0.0.0a0 *

Ah yep! I can help with this:

ERROR: Could not find a version that satisfies the requirement cudf==25.2.*,>=0.0.0a0; extra == "test" (from dask-cuda[test]) (from versions: 0.6.1.post1)
ERROR: No matching distribution found for cudf==25.2.*,>=0.0.0a0; extra == "test"

(build link)

When we publish cudf packages, their distribution names have a suffix appended with the CUDA major version. This error is happening because we don't publish a package called cudf... it's "cudf-cu11" for CUDA 11 and "cudf-cu12" for CUDA 12.

The problem here is that the [test] extra for the dask-cuda wheels has unsuffixed name "cudf" in it.

This is an interesting one ... since we only publish "dask-cuda" (no suffix) here, the same wheel will be pulled in regardless of CUDA version. So we can't depend on a single [test] extra to tell us what versions of dependencies to pull in, because some of those dependencies have to be CUDA-major-version-specific.

I can think of 2 ways to address this:

• not having any extras for testing dependencies, and just directly installing them
• having 2 extras, like [test-cuda11] and [test-cuda12]

I think we should try just directly installing them in CI. That'd mean:

1. prevent that invalid [test] extra from getting written into the wheel:

   dask-cuda/dependencies.yaml

   Lines 50 to 57 in d9c6996

   	py_test:
   	output: pyproject
   	pyproject_dir: .
   	extras:
   	table: project.optional-dependencies
   	key: test
   	includes:
   	- test_python

2. install the testing dependencies directly in ci/test_wheel.sh (follow this related example from cudf)

is there a pre-release staging area that it should be pointing at?

That's already happening in this job.

RAPIDS pre-release packages are published at https://pypi.anaconda.org/rapidsai-wheels-nightly/simple/, and the docker images we run wheel CI in have configuration pointing there: https://github.com/rapidsai/ci-imgs/blob/39aa63d9799dbc9b8268cbbffb2f4d0b39192e67/context/pip.conf#L5

[jameslamb]

Thanks! Left one suggestion for your consideration.

[jameslamb]

Suggested change

	python -m pip install -v --prefere-binary -r /tmp/requirements-test.txt
	# echo to expand wildcard before adding `[extra]` requires for pip
	python -m pip install $(echo ./dist/dask_cuda*.whl)
	# echo to expand wildcard before adding `[extra]` requires for pip
	python -m pip install \
	-r /tmp/requirements-test.txt \
	./dist/dask_cuda*.whl

I think we should group these pip install calls together.

That'll reduce the risk of creating an inconsistent environment, and give us a better chance of catching packaging issues.

For example, imagine if dask-cuda had a runtime dependency on numpy<2 but we had a pin of numpy>=2 in testing dependencies. With separate pip install calls, pip would happily downgrade numpy. With them combined, we'll get an informative, loud error saying "hey these requirements are incompatible".

[gforsyth]

Thanks for all the pointers, @jameslamb ! Still waiting on a few conda jobs, but the wheel tests are green, so this is probably ready for another look!

[jameslamb]

🙌🏻 looking pretty good!

Last suggestion... can you please pull the latest changes from branch-25.02 in here? I think that's a useful practice in general, but especially relevant for this PR because this PR is missing some changes related to dependency versions (#1419).

If we see everything pass and no issues in logs after that, I support merging this.

[jameslamb]

Seems ok to me... looks like the changes from #1406 doing the same thing in the conda Python test jobs hasn't been reverted yet.

[gforsyth]

Hey @jameslamb -- rebased and green

[jameslamb]

Looks great, thanks for working through this!

[jameslamb]

/merge