Indicate successful check

[bessman]

Two of the five testimonials in the README mention intentionally introducing errors to be sure ruff was even running. I admit I did the same when I first tried ruff. It's cool that ruff is so fast people aren't sure it ran at all, but perhaps it is also a UX problem?

When black finds nothing to complain about, it says:

All done! ✨ 🍰 ✨
<n> files left unchanged.

pylint:

Your code has been rated at 10.00/10

mypy:

Success: no issues found in <n> source files

Perhaps ruff could do something similar if no errors are found? For example:

$ ruff check .
Found 0 errors in <n> files 🎉

On the other hand, several linters are silent if they find nothing (pycodestyle, flake8, isort, etc.).

[zanieb]

I'm into a message if there are no errors and indicating the number of number of source files sounds nice. I'd prefer not to include an emoji.

[doolio]

On the other hand, several linters are silent if they find nothing (pycodestyle, flake8, isort, etc.).

I presume those that prefer that approach could still achieve it with the --quiet or --silent options.

[vladNed]

is this issue still available ? I would like to give it a go and implement a nice message output for successful checks.

I got inspired from black, as it always shows the cake when everything was ok

[zanieb]

Well it's not done but there are a couple existing pull requests

@hughhan1 opened a pull request but noted that @vinhocent had a better pull request. @konstin reviewed the latter one. I'm not sure what the status is. I'd love to have this done soon though!

[vladNed]

I kinda have an idea to also add the checked files to the diagnostics in order to display to the user how many files where checked after a successful run.

Will make a PR and maybe you guys take a look.

[konstin]

@zanieb Could you review #8631? I can solve the merge conflicts and merge after.

[alexeagle]

I think that users who are trying Ruff for the first time, can't believe the speed and want to see that Ruff is actually doing something are well-advised to introduce a lint violation and see that it's reported, as a way of learning the tool.

#8631 introduced output on success. This has been discussed with other linters:

• make the -s, silent output in case of success the default output golangci/golangci-lint#121 - always be silent following https://www.linfo.org/rule_of_silence.html
• eslint default stylish formatter maybe need successful messages output eslint/eslint#3495 (comment) - eslint is incredibly widely adopted and the person commenting here is one of the most prolific and respected developers in the Node.js ecosystem.
• From Add advice for fixing RUF008 when mutability is not desired #8853 requesting, the author observes
  "On the other hand, several linters are silent if they find nothing (pycodestyle, flake8, isort, etc.)."

There are tools which interpret non-empty output to mean that a developers attention is required, and empty output to mean the linter has nothing to report. For example in CI it might report your one-line "success" message as spam boxes in the results UI, where no output would have created no box.

I think rather than add an option, ruff should go back to the old silent-on-success behavior.

[zanieb]

Simply, I disagree.

I understand the Unix philosophy and agree with it in many cases, but I don't really see this as a friendly default interface which is an emphasized goal in our tooling.

You should be able to suppress this with -q if it matters for your use-case. I could see automatic suppression when we can't find an interactive terminal being reasonable, but this could also be pretty confusing for people.

I'm willing to hear more discussion and feedback.

There are tools which interpret non-empty output to mean that a developers attention is required, and empty output to mean the linter has nothing to report.

This is the purpose of exit codes. Is there a reason that's insufficient? Deprecation warnings?

[alexeagle]

I think exit codes don't express warnings well. Non zero exit code would terminate a build, which is an error semantic.

[zanieb]

Yeah I think there's an open question about how to elevate warnings to users. Most users don't see any of the deprecation warnings we display in CI and are surprised when things break.

[zanieb]

Note we write this to stdout and not stderr (which is where we emit things like warnings)