-
Notifications
You must be signed in to change notification settings - Fork 67
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
Improve config handling in cpp and python #644
Improve config handling in cpp and python #644
Conversation
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. |
b8146e0
to
f5652ea
Compare
/ok to test |
1 similar comment
/ok to test |
Forgot about cuFile's |
/ok to test |
/ok to test |
2 similar comments
/ok to test |
/ok to test |
# TODO: Wrap nicely, maybe as a dataclass? | ||
# <https://github.com/rapidsai/kvikio/issues/526> | ||
DriverProperties = cufile_driver.DriverProperties | ||
properties = cufile_driver.DriverProperties() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think having an instance of DriverProperties()
would suffice. So now the settable properties in cufile driver can be set in the following ways:
kvikio.cuda_driver.properties.<prop> = <value>
kvikio.cuda_driver.set("<prop>", <value>) # Can also be used in a "with" statement
kvikio.cuda_driver.set({"<prop>": <value>}) # Can also be used in a "with" statement
Let me know if this looks good enough to you @madsbk
55e849c
to
33b133e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we also want to use get
for configs like task_size
?
- To set one or more properties | ||
|
||
.. code-block:: python | ||
|
||
kvikio.cufile_driver.properties.set({"prop1": value1, "prop2": value2}) | ||
|
||
- To set a single property | ||
|
||
.. code-block:: python | ||
|
||
kvikio.cufile_driver.properties.set("prop", value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Include a context example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@@ -14,80 +14,86 @@ cdef extern from "<kvikio/defaults.hpp>" namespace "kvikio" nogil: | |||
OFF = 0 | |||
ON = 1 | |||
AUTO = 2 | |||
bool cpp_is_compat_mode_preferred \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This additional C++ function is needed.
@@ -100,17 +98,16 @@ def test_incorrect_open_mode_error(tmp_path, xp): | |||
|
|||
|
|||
@pytest.mark.skipif( | |||
kvikio.defaults.compat_mode(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a minor bug. By default, compat mode is AUTO
, not ON
. Here we need to resolve it by using is_compat_mode_preferred()
(which necessitates importing its C++ function as mentioned above).
@@ -11,6 +11,24 @@ CuFile | |||
.. autoclass:: IOFuture | |||
:members: | |||
|
|||
CuFile driver |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added this section, which is missing on the dev branch.
Done. Added the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
Only question is if we should raise a DeprecationWarning
?
My preference is usually for a An exception to this is if it's a component that's typically used by other libraries. Maybe we do want a |
Exactly, KvikIO is primarily used by other libraries :) |
We exclusively use FutureWarning in cuDF and have recommended all RAPIDS libraries should match that. It’s also how most PyData libraries we’ve studied handle deprecations, to ensure visibility. |
Thanks for the discussion. Interesting subtle difference between the two. I'll then keep the use of |
/merge |
Thanks for the review! |
## Description KvikIO has changed the function names of the config setters to improve clarity (rapidsai/kvikio#644). This PR updates the setter calls in cuDF accordingly. ## Checklist - [x] I am familiar with the [Contributing Guidelines](https://github.com/rapidsai/cudf/blob/HEAD/CONTRIBUTING.md). - [x] New or existing tests cover these changes. - [x] The documentation is up to date with these changes.
For posterity, some of our historical discussions around DeprecationWarning and FutureWarning can be found in:
Also worth noting that we have a pre-commit hook in cudf to enforce never using DeprecationWarning, see rapidsai/cudf#11251 and rapidsai/cudf#11255. |
Closes #642
Closes #526
This PR makes the following changes:
Improve config setter/getter
This PR lets the properties in
kvikio.defaults
andkvikio.cufile_driver
be set using a friendly Pythonic interface (C++ interface has also been adjusted for improved clarity). The expression below can appear standalone which sets the properties globally, or in awith
statement which sets the properties via a context manager.In addition, this PR supports the getter method:
Deprecate the old ways of setting configs
The
<prop>_reset
andset_<prop>
functions are now deprecated. Deprecation warnings (of typeFutureWarning
) are issued at runtime.Add Python function is_compat_mode_preferred
The C++ function
kvikio::defaults::is_compat_mode_preferred()
resolves and queries the current global compat mode. This PR introduces this function to Python.Python documentation update