Add configuration to promote/demote severity of messages
Opened this issue · 11 comments
Status Quo
Currently you can disable specific messages or severity classes (error, warning, refactor, convention), so to do pylint runs of various stringency, you could do one of
pylint -E ...pylint --disable=R,C,W ....pylint --disable=R,C ...
However, if you have a style guide that might mean one of the "convention" messages is a must-do, then you need to disable all the others, then you can bit-OR the exit code to fail a build on the refactor bit being set. Alternatively, parse the output (ick).
Desired feature
Add a configuration where you can map message codes/names to severity level.
For instance, if I say something like C0303=E or trailing-whitespace: error, and run pylint, even if there are no "true" error messages, a C0303 message would cause the exit code to have a 2 in it.
Help
I'd be willing to take a stab at a patch, but I'm also not sure if it could be done in a plugin just as well? I'm having some trouble figuring out how. The docs point me towards a learning cliff: "In general, a plugin is a module which should have a function register, which takes an instance of pylint.lint.PyLinter as input.", but even looking at the class spec it's not immediately obvious how to hook into it. Are there docs for that I'm not finding or simple (but non-trivial) plugins for example?
This sounds like it might be useful and it's a topic that is reoccurring from time to time. After a short look it seems this is possible with rubocop and ESLint.
This most likely needs to happen in core pylint, not as a plugin, since the plugins don't have this low level access for controlling the configuration and the exit codes. You can take a look in pylint/config.py where the configuration magic happens. One thought though is that it seems this feels like something that should go only in the configuration file, as I'm not sure how we can export this behaviour at CLI level. Regardless, this idea sounds like a good improvement, but would require some work.
Agree!
I think this feature is very good, and I need this feature. I want to lookup source code and how eslint is implemented.
mark it.
Subscribing to this - would be great to only exit non-zero in case of certain severity classes. Use case: during continuous integration, print warnings but still allow to exit zero. The --exit-zero flag isn't helpful here because it means even errors won't cause the CI pipeline to fail.
This can be achieved with a combination of --exit-zero and --fail-on so I'm labelling as minor.
I am want pylint to ONLY fail on errors/fatals, but STILL print/output the warnings. No command (such as --exit-zero & --fail-on=F,E) worked so far (see SO ). According to @Pierre-Sassoulas I should comment here.
As a workaround you can use https://github.com/reviewdog/reviewdog#readme which helps you fine tune those details and add some extra nice features.
Thanks, but I would like to use as little packages as necessary. Will pylint fix this issue?
Being able to change severity of specific rules would be extremely useful for us
Seems like we could look at a third party plugin to achive our goal.
If anyone has another to do this, may be share it here ?
@LvffY in a comment from PCManticore above:
This most likely needs to happen in core pylint, not as a plugin, since the plugins don't have this low level access for controlling the configuration and the exit codes.
That was years ago, so maybe it's changed. Does the SonarQube plugin you mentioned actually control the exit code of the pylint executable, or does it just modify the report it generates?
@nicktimko AFAIK if takes the output of pylint and just generates another report.