-
-
Notifications
You must be signed in to change notification settings - Fork 25.8k
TST allow categorisation of tests into API and legacy #29699
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
Conversation
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 assume documentation will come later?
Is there an associated GH issue to track what will move where and such?
At least for the moment, this is going to solve: #16241 -> it means that we need to have a API documentation page in line with the check that we are doing. Then, adding tests to other category would be for later. |
Yes, there will be a bunch of documentation work for this page: https://scikit-learn.org/stable/developers/develop.html I rather we settle with this API here and merge, and then work on API only tests dedicated in a different PR, and follow up PR to update our documentation. Along with other PRs here:
Developer API
|
Also for some historical context, @NicolasHug had some a lot of work in #16882, #16890, #17252, and #17361. But we ended up reverting them last minute before a release. |
I see! That's exciting. I always did find 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.
@adrinjalali Can you open an issue or comment on an issue that gives an overview on what the categories will be?
sklearn/utils/estimator_checks.py
Outdated
@@ -513,9 +522,14 @@ def _should_be_skipped_or_marked(estimator, check): | |||
return False, "placeholder reason that will never be used" | |||
|
|||
|
|||
def parametrize_with_checks(estimators): | |||
def parametrize_with_checks(estimators, legacy=True): |
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.
Does this need to be added to check_estimator
?
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'll add it.
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.
Can you open an issue or comment on an issue that gives an overview on what the categories will be?
We don't really know at this point what those categories are gonna be. API and "statistical" tests are probably the two we have, then there's array API, sample weight, and I'm not sure about the rest. My plan is to start going through them and to create the categories as we go, while having an overview once I start working on it.
sklearn/utils/estimator_checks.py
Outdated
@@ -513,9 +522,14 @@ def _should_be_skipped_or_marked(estimator, check): | |||
return False, "placeholder reason that will never be used" | |||
|
|||
|
|||
def parametrize_with_checks(estimators): | |||
def parametrize_with_checks(estimators, legacy=True): |
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'll add it.
Issue for test categories: #29703 |
@glemaitre I agree, but do you want this in this PR? I rather have that in a followup PR since adding all API tests would be quite large. |
Not in this PR, it was just to provide the big picture here. |
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.
We should add a test now to make sure that we have less test runnnings with legacy=False
.
sklearn/utils/estimator_checks.py
Outdated
@@ -533,6 +547,11 @@ def parametrize_with_checks(estimators): | |||
|
|||
.. versionadded:: 0.24 | |||
|
|||
legacy : bool (default=True) | |||
Whether to include legacy checks. |
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'm wondering if you should add a little note to mention that the legacy checks exists during the transition that we create the categorisation.
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.
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.
We should add new test to make sure that the length of the generator with legacy=True
is bigger than legacy=False
.
Enabling auto-merge and trying to make Debian build works |
This is a very minimal PR, allowing us to start working on categorisation of tests. The idea is:
parametrize_with_checks
, such asstatistical
, etc.cc @glemaitre @thomasjpfan @OmarManzoor @adam2392