[Rust] CUDA 13 support

[jameslamb]

Description

CUDA 13 support is rolling out across RAPIDS libraries: rapidsai/build-planning#208

The first pass at that only added that support in devcontainers, C++, conda packages, and wheels (#1273).

This issue tracks work to add CUDA 13 support for the cuvs Rust packages.

Benefits of this work

• allows cuVS Rust users to get the latest improvements in CUDA

Acceptance Criteria

• cuvs Rust packages can be used with CUDA 13

Approach

Decide on and document a CUDA support strategy for Rust packages here.

For example, there is a package published under the name cuvs at https://crates.io/crates/cuvs. Answer some of these:

• should that only ever support a single major CUDA version?
• is there a mechanism like the cuda-version on conda-forge (docs) that could be used to differentiate between builds targeting different CUDA versions?
• should suffixed packages like cuvs-cu13 be published?

Offline, @benfred mentioned that the cuvs Rust bindings might be usable across multiple CUDA major versions, as they just link to the available libcuvs.so... that should be validated and tested, but might mean no changes are needed here.

Implement any docs, build, packaging, testing, etc. changes required.

Notes

Some initial building and testing was set up in #1273

[benfred]

We're currently distributing rust packages for cuvs on crates.io . This is a source only distribution - we aren't distributing binary packages for rust. The rust build will pick up an existing libcuvs_c.so / libcuvs.so if it is present, and all of the cuda specific code is in libcuvs.so.

If libcuvs.so isn't present the rust build will attempt to build it itself - which is extremely slow, which is why we recommend users to install libcuvs via pip or conda first (and will need to install a cuda13 version). Having an option for a binary tarball here would also be extremely useful.

This should mean that the there isn't too much work to do for cuda13 builds for rust since we aren't distributing binary packages, but we should aim to test this in CI, and add documentation about how to install the cuda13 version of libcuvs.so via pip/conda etc to the rust docs.

[jameslamb]

Alright thanks for writing that up!

Great, we do already have builds in CI here targeting CUDA 12 and CUDA 13:

cuvs/.github/workflows/pr.yaml

Lines 182 to 193 in 890929e

	rust-build:
	needs: conda-cpp-build
	secrets: inherit
	uses: rapidsai/shared-workflows/.github/workflows/custom-job.yaml@branch-25.10
	# Artifacts are not published from these jobs, so it's safe to run for multiple CUDA versions.
	# If these jobs start producing artifacts, the names will have to differentiate between CUDA versions.
	strategy:
	fail-fast: false
	matrix:
	cuda_version:
	- '12.9.1'
	- '13.0.0'

But in #1273 I intentionally skipped the Rust publishing workflow. It sounds like maybe that won't need to change at all, or maybe should just be updated to use ONLY CUDA 13:

cuvs/.github/workflows/publish-rust.yaml

Lines 11 to 17 in 890929e

	rust-publish:
	runs-on: ubuntu-latest
	strategy:
	fail-fast: false
	matrix:
	cuda_version:
	- '12.9.1'

That + some docs updates and then not needing to update anything about the published packages or crates.io repo sounds great 😁

[jakirkham]

We could build a Conda package for the Rust binary. That way users could install a prebuilt binary without needing to build from source