-
Notifications
You must be signed in to change notification settings - Fork 456
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
Deprecate ModelFilter/DatasetFilter
#2028
Deprecate ModelFilter/DatasetFilter
#2028
Conversation
…method Moved all attributes from ModelFilter class to list_models arguments and added a filter query builder to build a query. Updated list_models to take both filter as an Iterable and also update the filter list based on other arguments in the method
Hi @druvdub! Thanks for the PR ❤️ I've tried to answer all of your questions in #1676 (comment). Please let me know if some parts are still unclear :) Regarding this PR, would it be possible to fix the styling? The PR change diff is very big at the moment due to some whitespaces/newlines added or removed. This makes the PR quite difficult to review. You can fix this with the following steps:
I believe the current changes were due to a "autoformat" or "format on save" feature in your IDE. Make sure to always run |
ModelFilter/DatasetFilter
Yup no worries, for some reason the makefile did not work, So I had to now manually run the ruff checks |
@Wauplin I think this should be all in terms of functionality changes. Should I update READMEs and completely remove And finally in terms of test changes should I just update the existing tests to take arguments instead of |
Thanks for all the modifications and taking care of the special cases @druvdub! I'll have a look at it on tomorrow if that's fine with you :) |
Yea sounds good to me :) |
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.
Thanks for the PR @druvdub! Logic-wise it looks good to me! 🔥 I left a couple of comments regarding the code + API but overall very nice one :) Once addressed, we will have to review some tests, especially if ModelFilter / DatasetFilter are used (since deprecation warning make the CI fail, on purpose). I can help on this part if needed (we have a expect_deprecation
decorator for tests that are meant to break).
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update. |
Hey @Wauplin I have addressed all the comments so far, and hopefully I can look at the tests now. In the meantime, is this expected? And similarly do we need to update the README.md files as well UPDATE: |
Might need to add another decorator for classes if we plan to use |
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.
Thanks for iterating over this PR! Implementation looks good to me now :)
In the meantime, is this expected?
Tips might not be formatted correctly if they contains special anchor (like urls). This is a known issue to solve in our parser but a workaround exists. A quick solution is to add newlines between the tag and the text itself (see comments below) and it should fix the documentation page. Thanks for noticing!
And similarly do we need to update the README.md files as well
AFAIK there is no mention of ModelFilter
/DatasetFilter
in the READMEs. No need to mention them "just" for the deprecation warning.
Might need to add another decorator for classes if we plan to use @expect_deprecation or potentially modify the tests to handle warnings with warning.catch_warnings unless we deprecate the filter argument in list_models and list_datasets.
We can already use @expect_deprecation
without needing to add a custom decorator. You just have to update the warning message in the code to add 'quotes'.
what I am thinking about are the additional scenarios
where we pass the the filter keyword arguments and ModelFilter as well. Do we need them assuming ModelFilter will be removed in sometime
No need to test the cases where direct parameters + ModelFilter are passed at the same time. It's counter-intuitive + the user would have a direct deprecation warning when implementing it (+it will only be supported for a few version, as you said).
Fix warning docstring Co-authored-by: Lucain <lucainp@gmail.com>
Sounds good, everything should be done now :) |
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.
@expect_deprecation
requires an argument (which method/class is deprecated)
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #2028 +/- ##
==========================================
- Coverage 82.34% 82.22% -0.12%
==========================================
Files 66 66
Lines 8257 8309 +52
==========================================
+ Hits 6799 6832 +33
- Misses 1458 1477 +19 ☔ View full report in Codecov by Sentry. |
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.
PR is ready to be merged! Good job @druvdub 🔥 🔥 🔥
woohoo great!! |
Related to #1676
Moved all attributes from ModelFilter class to list_models arguments and added a filter query builder to build a query. Updated list_models to take both filter as an Iterable and also update the filter list based on other arguments in the method