-
Notifications
You must be signed in to change notification settings - Fork 997
Fix warnings in dask-cudf test suite #20951
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
base: main
Are you sure you want to change the base?
Fix warnings in dask-cudf test suite #20951
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. |
|
/ok to test 7544eab |
|
/ok to test 2723bd7 |
|
/ok to test 15edec7 |
| return ngpus >= n | ||
|
|
||
|
|
||
| @pytest.fixture |
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.
Like you helped identify with the cudf_polars tests, should this be made module scope to not recreate this per test?
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 in c6bc789.
We previously used the loop fixture from distributed. I think we don't need that: we shouldn't really be sensitive to which event loop the test is running on these days.
jameslamb
left a comment
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 left one small non-blocking comment... do whatever you want with it. Otherwise looks good to me, approving from a ci-codeowners / packaging-codeowners perspective.
| # This warning comes from dask-expr, and is probably a consequence of | ||
| # cudf's NA handling differing from pandas' default handling, | ||
| # since we try to construct an int64 ndarray with NaNs. | ||
| @pytest.mark.filterwarnings("ignore::RuntimeWarning") |
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.
For my understanding... why are these being added as pytest markers instead of in the configuration in pyproject.toml alongside other warning filters?
I think it also may be helpful to limit this to only dask_expr instead of all RuntimeWarning, so you have a chance to see and react to other RuntimeWarnings besides the one the comment describes.
And example of that:
filterwarnings = [
...
"ignore::FutureWarning:sklearn",
"ignore::DeprecationWarning:sklearn",
...
]And docs on the syntax: https://docs.python.org/3/library/warnings.html#describing-warning-filters
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.
My reasoning was to make it local: maybe it's just a personal preference, but I like the idea of putting general rules in the pyproject.toml (error by default) but override that locally in specific modules / functions.
I'll adopt your suggestion to filter this to a module.
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.
Yes, add a module filter, otherwise this is fine to define here. We only need to use pyproject.toml for global (or far-reaching, or large-but-temporary) ignores.
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.
Sounds good, thanks for explaining that.
| # This warning comes from dask-expr, and is probably a consequence of | ||
| # cudf's NA handling differing from pandas' default handling, | ||
| # since we try to construct an int64 ndarray with NaNs. | ||
| @pytest.mark.filterwarnings("ignore::RuntimeWarning") |
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.
Yes, add a module filter, otherwise this is fine to define here. We only need to use pyproject.toml for global (or far-reaching, or large-but-temporary) ignores.
Description
This fixes the warnings in the dask-cudf test suite, so that the tests run with
-Werror.Checklist