Skip to content
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

Add configuration to promote/demote severity of messages #2293

Open
nicktimko opened this issue Jul 15, 2018 · 12 comments
Open

Add configuration to promote/demote severity of messages #2293

nicktimko opened this issue Jul 15, 2018 · 12 comments
Labels
Enhancement ✨ Improvement to a component High priority Issue with more than 10 reactions Needs specification 🔐 Accepted as a potential improvement, and needs to specify edge cases, message names, etc.

Comments

@nicktimko
Copy link

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?

@PCManticore
Copy link
Contributor

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.

@PCManticore PCManticore added the Enhancement ✨ Improvement to a component label Aug 10, 2018
@daoiqi
Copy link

daoiqi commented Apr 13, 2020

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.

@lowlyocean
Copy link

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.

@Pierre-Sassoulas
Copy link
Member

This can be achieved with a combination of --exit-zero and --fail-on so I'm labelling as minor.

@Pierre-Sassoulas Pierre-Sassoulas added the Minor 💅 Polishing pylint is always nice label Jul 6, 2022
@Pierre-Sassoulas Pierre-Sassoulas added the Needs PR This issue is accepted, sufficiently specified and now needs an implementation label Jul 21, 2022
@oconnor127
Copy link

oconnor127 commented Oct 10, 2022

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.

@jooola
Copy link

jooola commented Oct 10, 2022

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.

https://github.com/reviewdog/reviewdog#reviewdogyml

@oconnor127
Copy link

Thanks, but I would like to use as little packages as necessary. Will pylint fix this issue?

@DanJBower
Copy link

Being able to change severity of specific rules would be extremely useful for us

@LvffY
Copy link

LvffY commented Nov 9, 2022

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 ?

@Pierre-Sassoulas Pierre-Sassoulas pinned this issue Mar 9, 2023
@Pierre-Sassoulas Pierre-Sassoulas added Needs specification 🔐 Accepted as a potential improvement, and needs to specify edge cases, message names, etc. and removed Needs PR This issue is accepted, sufficiently specified and now needs an implementation labels Mar 9, 2023
@nicktimko
Copy link
Author

@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?

@LvffY
Copy link

LvffY commented May 17, 2023

@nicktimko AFAIK if takes the output of pylint and just generates another report.

@tbutler-qontigo
Copy link

@nicktimko AFAIK if takes the output of pylint and just generates another report.

yes it just reformats the report - you need https://pypi.org/project/pylint-exit/ if you want to remap the exit code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement ✨ Improvement to a component High priority Issue with more than 10 reactions Needs specification 🔐 Accepted as a potential improvement, and needs to specify edge cases, message names, etc.
Projects
None yet
Development

No branches or pull requests

10 participants