-
Notifications
You must be signed in to change notification settings - Fork 57
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
Remove globally disabled pylint
messages
#522
Remove globally disabled pylint
messages
#522
Conversation
Codecov Report
@@ Coverage Diff @@
## main #522 +/- ##
=======================================
Coverage 87.54% 87.54%
=======================================
Files 151 151
Lines 5943 5943
Branches 771 771
=======================================
Hits 5203 5203
Misses 507 507
Partials 233 233
|
df4e80b
to
b62235c
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.
Thanks for taking care of this! I left a bunch of comments, all of which are mostly out of curiosity. I think the changes are fine already. :)
.github/workflows/pylint_check.py
Outdated
If you are not sure what exactly you are supposed to do, or if you think that this | ||
message is wrong please feel free to ping @nathanaelbosch. | ||
message is wrong please feel free to ping @marvinpfoertner or @nathanaelbosch. |
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 adding this. Purely out of curiosity: how well do you think these "ping XYZ" error messages will age?
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.
Good point, I guess we can take this line out and have people ping any maintainer instead
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 completely agree, people should open issues instead of pinging people (or ping them in the new opened issue) 👍
pyproject.toml
Outdated
# In functions/methods which are part of the public API, we often change the type of argument variables when normalizing inputs for internal processing, | ||
# e.g. we might use `pn.utils.as_numpy_scalar` to cast a `float` into a `np.double` or a `np.ndarray` into a `RandomVariable` by using `pn.randvars.asrandvar`. | ||
"redefined-variable-type", | ||
# Many more `disable`s are defined in `./tox.ini` on a per-module basis! |
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.
[minor] would this be something that is removed once the last per-module is removed?
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. To be honest, I don't think this line is particularly well-placed here anymore. I'll remove it.
pyproject.toml
Outdated
# Extensions that might be of interest in the future: | ||
# "pylint.extensions.check_elif", | ||
# "pylint.extensions.docparams", |
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.
[minor] now that these lines are touched anyway, is this well-placed here? Would it be better as an issue/discussion instead?
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 just enable the plugins and disable their messages per-package.
That way we can resolve them like any other message.
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.
Is it already clear that we want those enabled? Depending on that I agree that you could just enable them, or we might need a discussion on what we actually want to enforce.
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 certainly want docparams
enabled and check_elif
is also a good idea. I'll enable it for now and we can take it out if it causes trouble in the future. Is this fine @pnkraemer @nathanaelbosch?
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 me this is fine. docparams will detect changes that one often forgets when refactoring (at least I do...). check_elif seems okay to me as well
.github/workflows/pylint_check.py
Outdated
If you are not sure what exactly you are supposed to do, or if you think that this | ||
message is wrong please feel free to ping @nathanaelbosch. | ||
message is wrong please feel free to ping @marvinpfoertner or @nathanaelbosch. |
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 completely agree, people should open issues instead of pinging people (or ping them in the new opened issue) 👍
pyproject.toml
Outdated
# Extensions that might be of interest in the future: | ||
# "pylint.extensions.check_elif", | ||
# "pylint.extensions.docparams", |
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.
Is it already clear that we want those enabled? Depending on that I agree that you could just enable them, or we might need a discussion on what we actually want to enforce.
pylint src/probnum/randvars --disable="too-many-arguments,too-many-locals,too-many-branches,too-few-public-methods,protected-access,unused-argument,no-else-return,duplicate-code,line-too-long,missing-function-docstring" --jobs=0 | ||
pylint src/probnum/utils --disable="no-else-return,line-too-long" --jobs=0 | ||
# Benchmark and Test Code Linting Pass | ||
# pylint benchmarks --disable="unused-argument,attribute-defined-outside-init,missing-function-docstring" --jobs=0 # not a work in progress, but final |
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.
Is this comment supposed to indicate what the final pylint exceptions should be?
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
@pnkraemer @nathanaelbosch I incorporated your review comments. |
In a Nutshell
This PR removes most globally disabled
pylint
messages.Detailed Description
When we introduced
pylint
for linting, we decided to disable different messages on a package level viatox.ini
in order to be able to usepylint
in our CI pipeline while keeping the flexibility to improve one package at a time. However, we noticed that this way we lacked a "global" run linting the package as a whole. Consequently, we decided to disable the union of all disabled messages to the globalpylint
configuration to be able to runpylint
locally.Unfortunately, this caused the CI to accept code that will not be accepted by our long-term
pylint
config, even if the message was removed from the per-package disable list.This PR
pylint
messages frompyproject.toml
except the ones which we decided to keep long-term,tox.ini
,pylint
configuration inpyproject.toml
,pylint
pass totox.ini
, andpylint_check.py
script from the CI to ensure that the messages disabled in the global linting pass are exactly the union of the messages disabled in the per-module linting passes.Related Issues
Closes #469.