`cuda_toolkit_check` fails on fresh install as `cuda-bindings` is not declared in dependencies

[jayavenkatesh19]

While testing out #137, I came across an interesting issue.

On a fresh environment with our declared dependencies (cuda-core>=0.6.0), rapids doctor fails with this message:

cuda_toolkit_check failed
  cuda.bindings 12.x or 13.x must be installed

Looking through the cuda-core docs, cuda-bindings is only pulled in through extras (cuda-core[cu12] or cuda-core[cu13]). So while installing the wheel, everything passes through smoothly but the cuda_toolkit_check throws an error on the first run.

I think one way to fix this would be to add cuda-bindings >=12,<14 to the dependencies.yaml file, and let pip decide on the specific version to install (it worked for me when I tested it out on a CUDA 13 system) , but I am unsure if this would lead to any issues. Adding the [cu12] or [cu13] extras isn't really an option as we want rapids-cli to be used on environments with varying cuda versions.

I think the bare pip install cuda-core shouldn't silently produce a broken install when cuda-bindings is an essential dependency but we should find a way to fix this downstream.

[jayavenkatesh19]

Upon discussing with the folks from cuda-python, we decided on a version pin of cuda-bindings>=12.9.6,!=13.0.*,!=13.1.*

NVML APIs that are used in this project and in cuda.core.system first landed in cuda-bindings 12.9.6 (for CUDA 12) and 13.2.0 (for CUDA 13). The constraint makes sure that the 13.0/13.1 wheels are excluded which pre-date these changes

These NVML APIs are backward compatible and I verified that cuda-bindings 12.9.6 works on a CUDA 13 environment (driver 580), and cuda-bindings 13.2.0 works on a CUDA 12 environment (driver 535). All rapids doctor checks pass in both directions, so compatibility shouldn't be affected based on the major of cuda-bindings