-
Notifications
You must be signed in to change notification settings - Fork 278
Move pathfinder to cuda-python top level
#723
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
fbdebfa
731256d
6e0ec6c
07e1385
68aa8d5
fafa998
4eff7d2
db0f540
9fea2e7
c494ef2
78b8c6d
5690d96
81b9bd9
b9be5cb
79a8019
975ba0b
3678fb4
c25184e
58b2513
050f857
1933869
50f4f8e
787236c
5b5078b
13e08ae
97f9dc8
e18cf05
b015bbe
36491c8
c6187db
346e8b9
9207966
3682f7d
7742c5c
92c8441
a5b7190
db0ea56
9a9f1d7
aac1cf7
989db08
222df6c
0b8af00
f902dc9
481f8de
fd18e1e
796bd46
06763af
b2135cf
bf48142
135a37d
48c6d63
7ab201a
9f3e9a4
00c8b6a
034286a
aaed5f2
9d8c70c
8440f90
98ae874
9686c2f
f3c0006
8f015d2
9f17cd1
db7933a
1b9a929
b69bf23
80ebbda
1c8d315
52e1369
70d1c14
342ca49
4e0033c
74ef126
5e85328
46fd972
428a2dc
4096885
5e6c7e5
d787a4c
60918d5
933a889
c0509be
eedf658
58ca181
b73f421
88c4ebc
ee19b0c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,23 @@ | ||
| # SPDX-FileCopyrightText: Copyright (c) 2025 NVIDIA CORPORATION & AFFILIATES. All rights reserved. | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
|
|
||
| from cuda.pathfinder._dynamic_libs import load_nvidia_dynamic_lib as _load_nvidia_dynamic_lib | ||
| from cuda.pathfinder._dynamic_libs.load_dl_common import LoadedDL | ||
| from cuda.pathfinder._dynamic_libs.supported_nvidia_libs import SUPPORTED_LIBNAMES as SUPPORTED_NVIDIA_LIBNAMES | ||
|
|
||
| __all__ = ["SUPPORTED_NVIDIA_LIBNAMES", "load_nvidia_dynamic_lib"] | ||
|
|
||
|
|
||
| def load_nvidia_dynamic_lib(libname: str) -> LoadedDL: | ||
| """Load a NVIDIA dynamic library by name. | ||
|
|
||
| Args: | ||
| libname: The name of the library to load (e.g. "cudart", "nvvm", etc.) | ||
|
|
||
| Returns: | ||
| A LoadedDL object containing the library handle and path | ||
|
|
||
| Raises: | ||
| RuntimeError: If the library cannot be found or loaded | ||
| """ | ||
| return _load_nvidia_dynamic_lib.load_lib(libname) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You could define this wrapper function in the
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This file is meant to be the public API in one view.
I understood exactly that was your goal: a flat list of available APIs. Note that I moved the docstring here.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Indeed, everything we define (or import) here that is not prefixed with
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That would make the public API far less obvious. E.g. to see the docstring, they'd need to open a private file.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think that's true. They could still do: from cuda.path_finder import load_nvidia_dynamic_lib
help(load_nvidia_dynamic_lib)Same as they would do now?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That'll only work interactively. What I have now can be inspected in obvious ways directly in the sources, e.g. when looking at the sources on github. I can send URLs pointing to specific APIs in this init.py file. Each function here will just be: That's exactly the public API, with a one-line call that's easy to ignore. What's the point of hiding that away, especially hiding away the docstring and the type hints?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The docstrings and type hints would also get picked up:
Those are primarily the ways consumers of a package interact with docstrings or type hints, rather than looking directly at the source.
It tightens the scope of
As examples, we can look at the
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The most important job: Show the public API You didn't answer why you want to hide that away.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm advocating for keeping function and type definitions outside of The main reason I'm advocating for that is because Defining functions and types beyond that serves to clutter I would argue it makes the code base less navigable than more for people looking at the source. Do I expect the function If this all seems nitpicky, I apologize. While I do have a strong opinion here, I don't mind at all if another reviewer (or you, as the author of this PR) made the final call about this.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. cuda.core's |
||
This file was deleted.
Uh oh!
There was an error while loading. Please reload this page.