Conceal output of tools that succeeded

[neob91-close]

We probably don't need to see the output of tools unless they fail. Hiding successful output would make pinpointing issues much easier.

The only scenarios I can think of where we might want to see the output even if the tool succeeds are:

• black and isort when using --fix: were any files changed?
• mypy with reveal_type: what's the revealed type?

Not sure if we should worry about these though.

[neob91-close]

CC @nsaje @vtclose

[AlecRosenbaum]

When using --fix I think we should always show output. I definitely want to know which files were modified. Often I have multiple unstaged changes locally, and only commit some chunks at a time. Seeing what files changed makes it easier to know what files I need to look at/re-stage

For mypy with reveal_type -- if I am debugging a typing-related problem then I'm probably just going to run mypy directly instead of repeatedly using lintlizard. So probably not a big deal. Other linting tools will probably fail if there's an unbound reveal_type anyway

[nsaje]

I think black exits with a non-zero code if it has to do any sort of fixes, so lintlizard would see that as a "failed" execution in any case

[AlecRosenbaum]

I don't believe that's true. black always exits with 0 even if it fixes formatting in some files. It'll only exit with 1 if it's running --check

[nsaje]

Yep, you're right. I assumed it returned 1 because I know pre-commit.com doesn't follow through with the commit if black does any changes, but it must have some other way of deciding to stop - probably checking for the presence of unstaged changes.

[neob91-close]

Both isort and black output the files that were changed, so I'm thinking we could extract that information and display it in lintlizard's summary.

[AlecRosenbaum]

Extracting information from the command output seems brittle

[neob91-close]

I agree, but we could mitigate that by adding tests.
An alternative would be to check which files were changed directly, but I don't like that idea.