Repository navigation
[FEA]: Support LoadedDL.from_distribution #759
Description
Is this a duplicate?
- I confirmed there appear to be no duplicate issues for this request and that I agree to the Code of Conduct
Area
cuda.bindings
Is your feature request related to a problem? Please describe.
Numba would like to report to the user not only the path it found it's dependencies on, but also the distribution that they came from. For instance consider the output of numba -s:
CUDA Libraries Test Output:
Finding driver from candidates:
libcuda.so
libcuda.so.1
/usr/lib/libcuda.so
/usr/lib/libcuda.so.1
/usr/lib64/libcuda.so
/usr/lib64/libcuda.so.1
Using loader <class 'ctypes.CDLL'>
Trying to load driver... ok
Loaded from libcuda.so
Mapped libcuda.so paths:
/usr/lib/x86_64-linux-gnu/libcuda.so.535.161.08
Finding nvvm from Conda environment (NVIDIA package)
Located at /mambaforge/envs/myenv/nvvm/lib64/libnvvm.so.4.0.0
Trying to open library... ok
Finding nvrtc from Conda environment (NVIDIA package)
Located at /mambaforge/envs/myenv/lib/libnvrtc.so.12.9.86
Trying to open library... ok
Finding cudart from Conda environment (NVIDIA package)
Located at /mambaforge/envs/myenv/lib/libcudart.so.12.9.79
Trying to open library... ok
Finding cudadevrt from Conda environment (NVIDIA package)
Located at /mambaforge/envs/myenv/lib/libcudadevrt.a
Checking library... ok
Finding libdevice from Conda environment (NVIDIA package)
Located at /mambaforge/envs/myenv/nvvm/libdevice/libdevice.10.bc
Checking library... ok
Include directory configuration variable:
CUDA_INCLUDE_PATH=/usr/local/cuda/include
Finding include directory from Conda environment (NVIDIA package)
Located at /mambaforge/envs/myenv/targets/x86_64-linux/include
Checking include directory... ok
Describe the solution you'd like
It would be useful if the LoadedDL class supported a from_distribution property that reported the source, such as wheel, conda or system ctk.
Describe alternatives you've considered
Without this, using pathfinder would require decoding the source distribution from the path supplied by pathfinder if we want to maintain the information currently supplied by the output.
Additional context
No response
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
brandon-b-miller commentedon Sep 24, 2025
Discussed some high level ideas around this with @rwgk who suggested returning a small dataclass that contains the source of the library as well as the ctk version. Given that we have full flexibility to choose the API for this I'd support including as much information as possible to start out with, so maybe let's begin with the goal of
LoadedDl.from_distributionreturning aDistributionclass with adistributionand acuda_versionattribute.distributioncould be a string that reports one of{'site-packages', 'Conda', 'system', 'CUDA_HOME'}, also as suggested by @rwgk, andcuda_versioncould be string or major/minor version tuple.As a starting point I'd suggest expanding the ctor of
LoadedDLto expect either aDistributionobject or one or both of the attrs needed to construct one, then, perhaps we can populate the info wherever we instantiate the class we intend to return.rwgk commentedon Sep 24, 2025
Sounds great! At the danger of slipping into bike shedding:
Alternatives to
distribution:pkg_kind,pkg_system(to have something less generic, not as prone to ambiguity / misunderstanding)A
namedtuplein the style ofsys.version_infowould seem great.pathfinderusable as a full replacement forcuda_paths.pyinnumba-cuda#1036