Migrate pynvml to cuda.core.system

[mdboom]

Migrates from pynvml.py to the new Cython/cybind-based cuda.core.system API.

[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.

[ncclementi]

I was trying to install this in Colab for example to give it a try and see if it works as expected, and I ran into an installation ERROR

ERROR: pip's dependency resolver does not currently take into account all the 
packages that are installed. This behaviour is the source of the following dependency conflicts.
torch 2.10.0+cu128 requires cuda-bindings==12.9.4; platform_system == "Linux", but you 
have cuda-bindings 13.2.0 which is incompatible.
cuda-python 12.9.4 requires cuda-bindings~=12.9.4, but you have cuda-bindings 13.2.0 which is incompatible.
numba-cuda 0.22.2 requires cuda-core<1.0.0,>=0.3.2, but you have cuda-core 1.0.1 which is incompatible.
dask-cuda 26.2.0 requires cuda-core==0.3.*, but you have cuda-core 1.0.1 which is incompatible.

It seems to be updating cuda bindings to the latest, which is to aggressive for most CSP.

I understand that the numba cuda version in colab is super old. So we can report that back and see if we can get them to upgrade.

All that being said, we can run the script. At the moment we are running the script to check the environment, but it seems like with this changes installing the rapids-cli is modifying that environment.

I'd like to know what @jacobtomlinson, @jayavenkatesh19 and @mmccarty think here.

[mdboom]

I was trying to install this in Colab for example to give it a try and see if it works as expected, and I ran into an installation ERROR

ERROR: pip's dependency resolver does not currently take into account all the 
packages that are installed. This behaviour is the source of the following dependency conflicts.
torch 2.10.0+cu128 requires cuda-bindings==12.9.4; platform_system == "Linux", but you 
have cuda-bindings 13.2.0 which is incompatible.
cuda-python 12.9.4 requires cuda-bindings~=12.9.4, but you have cuda-bindings 13.2.0 which is incompatible.
numba-cuda 0.22.2 requires cuda-core<1.0.0,>=0.3.2, but you have cuda-core 1.0.1 which is incompatible.
dask-cuda 26.2.0 requires cuda-core==0.3.*, but you have cuda-core 1.0.1 which is incompatible.

It seems to be updating cuda bindings to the latest, which is to aggressive for most CSP.

I understand that the numba cuda version in colab is super old. So we can report that back and see if we can get them to upgrade.

All that being said, we can run the script. At the moment we are running the script to check the environment, but it seems like with this changes installing the rapids-cli is modifying that environment.

I'd like to know what @jacobtomlinson, @jayavenkatesh19 and @mmccarty think here.

Can you move to cuda-python 12.9.6? That should hopefully be enough to satisfy the dependencies here. Unfortunately, 12.9.4 doesn't have the NVML functionality at all.

[ncclementi]

Can you move to cuda-python 12.9.6? That should hopefully be enough to satisfy the dependencies here. Unfortunately, 12.9.4 doesn't have the NVML functionality at all.

@mdboom The problem is that in the case of rapids-cli, we use this library, among other things to run rapids debug, which asses the state of the environment, like what packages are installed. This varies from CSP to CSP, and what might be a solution now for colab, might not be a solution for another CSP. Plus we do not control how things get installed, like this is not a new environment, this is their built in environment

It's also bit problematic for us, that installing rapids-cli, will mean to upgrade a package in the environment, that we are trying to collect information on.

We talked about this with the team, and decided that we will hold of on the migration until the cuda.core.system is more mature.

cc: @jayavenkatesh19

[leofang]

We talked about this with the team, and decided that we will hold of on the migration until the cuda.core.system is more mature.

I think "more mature" is an ambiguous term. This is ultimately yet another packaging (aka dependency hell) problem and by "more mature" we don't mean that there is anything actionable for cuda.core, we mean to wait until at least some older dependencies like CUDA 12 are uniformly dropped across RAPIDS customers, which is fine with me. Just wanna make sure we're on the same page 🙂