Solvedpylint --fail-under flag

Is your feature request related to a problem? Please describe

Hi all,

I like running pylint on my codebase on Travis as a check, but I think it's unreasonable to fix all the warning, errors and other messages pylint issues (I do want to see them though). What I would like is to have a 0 exit code if and only if the final score is more than a certain value (say, 9). As time progresses and the project matures I can then increase that score threshold to higher and higher values.

Currently, so long as pylint finds any problem with my code and issues a message, it exits with a non-zero exit code, signalling failure to Travis.

Describe the solution you'd like

A --fail-under <score> flag, also configurable in a .pylintrc file. If the final score is more than the specified score, it's considered a success and pylint exits with exitcode 0. Otherwise, it's considered a failure and pylint exits with it's current exitcode based on the messages issued.

Current work-around

At the moment I call pylint as following in Travis, but that trashes the actual usefull output. And is hard to read.
test $(bc -l <<< $(pylint --disable=fixme vermouth | sed -re "s_.* ([0-9\.]+)/10.*_\1>9_;t;d")) -eq 1

Thanks for all the hard work so far, keep it up! :)

21 Answers

✔️Accepted Answer

@PCManticore @brycepg Please consider re-opening this. This is a useful feature. coverage also has similar feature. It is not that complicated.

Other Answers:

This seems like such an obvious feature that I am quite puzzled that this is not possible.

@ChristopherRabotin You can find my version here: https://github.com/marrink-lab/vermouth-martinize/blob/master/run_pylint.py
And you can call it like such: python run_pylint,py --fail-under=7, which will do as you expect, while still passing through all command line arguments, and without needing output redirection.

Hey @radeklat Thanks for the additional argument and examples. After reading your comment, I had a change of heart and I could see this feature being useful for large adoption of pylint in various codebases. I already mentioned my favourite flow of integrating pylint in a codebase in a past comment, but as you mentioned, sometimes it's not possible to fix all messages of a given kind, and that's where this new flag comes in. Thanks again.

Any chance this can be re-opened? I'd be happy to code up the fix myself.

This would be invaluable in an organization where most folks are resilient to even using git and CI... The on-boarding must be as easy as possible, and providing a simple .pylintrc file along with three lines to add to the .yml file is perfect.

More Issues: