Add _get_cuda_version_from_cuda_h() in cuda_core/build_hooks.py

[rwgk]

WIP — Will work on it more asap.

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[rwgk]

/ok to test

[rwgk]

Local testing with a venv that does not have cuda-bindings:

pip install -v . --group test

...
Building wheels for collected packages: cuda-core
  Building wheel for cuda-core (pyproject.toml): started
  Running command Building wheel for cuda-core (pyproject.toml)
  CUDA paths: ['/usr/local/cuda']
  CUDA_VERSION from /usr/local/cuda/include/cuda.h: 13000
...

$ pip list
Package    Version
---------- -------
cuda-core  0.3.3a0
Cython     3.1.4
iniconfig  2.1.0
numpy      2.3.3
packaging  25.0
pip        25.2
pluggy     1.6.0
Pygments   2.19.2
pytest     8.4.2
setuptools 80.9.0

[github-actions]

Doc Preview CI
🚀 View preview at https://nvidia.github.io/cuda-python/pr-preview/pr-1085/
https://nvidia.github.io/cuda-python/pr-preview/pr-1085/cuda-core/
https://nvidia.github.io/cuda-python/pr-preview/pr-1085/cuda-bindings/
https://nvidia.github.io/cuda-python/pr-preview/pr-1085/cuda-pathfinder/
Preview will be ready when the GitHub Pages deployment is complete.

[leofang]

Calling nvidia-smi is better because it does exactly the same thing under the hood (opening up libcuda/nvcuda and getting the driver version), but it is cross-platform and so takes much less lines of code, and it is a good habit to keep the code surface in build_hook.py small because it is not easy to write tests for modules outside of the source tree.

[rwgk]

Calling nvidia-smi is better because it does exactly the same thing under the hood (opening up libcuda/nvcuda and getting the driver version), but it is cross-platform and so takes much less lines of code, and it is a good habit to keep the code surface in build_hook.py small because it is not easy to write tests for modules outside of the source tree.

The main reason I was leaning into it is that I think it'd be a useful addition to pathfinder.

It's more lines of code only because subprocess is being reused.

Assume that the code I added lives in pathfinder, you'd just reuse that and have a more secure, more robust, and faster (which doesn't matter here, but is useful in general) solution with even less lines of code.

[leofang]

The main reason I was leaning into it is that I think it'd be a useful addition to pathfinder.

Why would the pathfinder need to expose the driver version check as a public API? Or you only had the driver loading part in mind?

[leofang]

This snippet is all we need for Windows and the rest can go. This way we just need one function to encapsulate driver version fetching in a cross-platform fashion. The platform check can happen inside the callee, not the caller.

[rwgk]

The main reason I was leaning into it is that I think it'd be a useful addition to pathfinder.

Why would the pathfinder need to expose the driver version check as a public API?

It'd be useful in general, not just here. It's just a few lines of Python code that is very similar to other functionality in pathfinder, and does not introduce any new dependencies. Having the function there, would make what's needed here a no-brainer.