Are there any linter or type check packages with a "report only" function?

Python Help
1

Hello.

For personal projects where I am the only person working on it, I like to do my main checks locally by leaning on githooks. I have a pre-commit Bash script that runs checks for isort, black, flake8, and mypy. If any of those fail, the script exits with an exit code of 1. Which obviously halts the commit. The output looks like the following. Sometimes I color code the pass and fail green / red, other I don’t.

Pass: isort passed
Pass: black passed
Fail: isort failed
Pass: mypy passed

Then I can run whichever failed manually and get the specifics, or I can echo the errors on a fail in the order I want / where I want in the output. Giving me a little more control on my output and making it easier to glean failure info.

Something I have to navigate is, how each library handles their output differently. They each do their own thing on success and failure. I get around that by redirecting the output like - black --check $directory_to_check > /dev/null 2>&1. That allows me to simply report on the exit code and not have four different pieces of information all output differently at the same time. (Whether than is a success or falure for any of the four checks.)

I was modifying my pre-commit script today and it made me wonder if there are any linter or type check libraries other than flake8 and mypy that have a sort of “report-only” flag or function? Meaning, they have an option to simply return a 1 or 0 and nothing else, allowing you to report on a pass or fail? The point being, then you can build your own pass fail logic around it without having to redirect the output like a madman.

Thanks.

2

It is so simple to redirect output when you do not want it, not sure why you think this is not good enough.

3

I didn’t say it wasn’t necessarily “good enough”. I’m more curious if there are any linters or type checkers with a sort of report only option. It’s interesting some libraries get in the way more than they need to. It’s more curiosity.

I also think the Python pre-commit library adds more overhead and complicates things more than necessary. Githooks are very simple. They rely on an exit code of 1 or 0. Beyond that, you don’t need the yaml files and all of that. Just write some simple Bash and exit with the code you want. Git even comes with samples in .git. But that’s a different topic.

I just feel things could get out of the way more in general when you want them to and it got me thinking what is out there and how do they each handle success / fail. isort for example just carries on with a success. Which is exactly what you’d expect and is perfect for building logic on top.

4

Report only suggested to me that you get the output always, but the exit code is always 0.

5

It seems like you’re asking for e.g. black --check --quiet SRC? The --check turns off reformatting, and --quiet turns off the output. isort has the same options, I don’t know about the others.

6 
pylint --output=report.txt some_python_file.py
7

--quiet doesn’t turn off everything. It just stops black from showing any non critical output. I already do --check with everything and --quiet with isort.

I was reading Black’s docs earlier to see if they did anything like I wrote about above and they actually talk about silencing errors like my original post asks about. They recommend redirecting the output in a similar way - 2>/dev/null. Which actually makes me feel good about myself (HA!) because I came to my solution on my own and the fact they mention how in the docs - means other people have asked for / wanted the same thing.

@hansgeunsmeyer That’s a really cool feature. I’ll test it out and dig into pylint!

Thanks, all. The info here and digging through the docs lets me know that redirecting is a decent way to handle this. I appreciate all of the responses!

8

I was looking through how pre-commit handled this. This library outputs like;

black........Passed
flake8.......Passed

Which is pretty similar to how I output mine. I was curious if it was redirecting the output as well and it appears so. It appears to be redirecting by doing this - > /dev/null.

I am going to play with this library and peek behind the scenes to see how it handles other things.

I understand that this library gives other libraries a way to ship pre-written githooks, but I really feel like it adds un-needed complexity. I am certain I feel this way due to a lack of understanding of what all pre-commit can do / what it does behind the scenes for us.

I looked at some of the bigger projects and examined their pre-commit yaml files - Poetry and Black being two of them.

I’m really curious what the library writes to the pre-commit file under .git/hooks/ and how it ties things in overall. Especially when using args.

Thanks again, everyone.

Again, not trying to achieve anything. I am just going down a rabbit-hole to learn and feed my curiosity.

Edit
I have a pretty good handle on how pre-commit work under the hood so far.

I looked into ruff. It is highly customizable. Does a lot of what I was hoping a linter out there did. It hits all of the marks of what I was looking for and then some. Excited to play with it.

https://docs.astral.sh/ruff/linter/#exit-codes

Thanks again, everyone.