Switch (some) linting to ruff

[akx]

Large projects such as Pandas are switching their linting (partially) to the fast ruff linter, see e.g. pandas-dev/pandas#50160, for a much nicer developer experience.

I opened a PR to do so in HA core too (home-assistant/core#86224) but I was told I jumped the gun and discussion should be had first.

[frenck]

Please list out the advantages and disadvantages comparing the solutions when making a proposal for a change.

In this specific case, there (for example) are differences in rules supported. What would get lost in this? What would be gained?

While I could suggest to make a shadow run of ruff next to what we already have, it seem to go again the goal you mentioned in the linked PR

For the record, I think this change would be a nice win from an energy conservation viewpoint – no need to have CI boxes and dev machines churn inefficiently for minutes when the same work can be done in seconds.

So, I guess that isn't an option.

[scop]

I guess a temporary shadow run for some time would be quite acceptable, it'd pave way for switching over.

ruff seems like a complete game changer for Python linting. My initial impressions are such that I'm already looking into dropping all others in my projects (keeping just black and mypy which are orthogonal), even willing to trade some linting coverage in exchange for the performance and ease of maintenance. Looking at the list, I don't think I'd even be missing much, if anything. Perhaps something from pylint that's not covered by the wealth of assimilated flake8 plugins' functionality.

That's speaking just for myself, for HA I agree a closer examination and more testing is in order. At least the custom in-tree pylint plugins will need addressing before switching completely over some time. But I see replacing pylint is not being suggested at all at this point.

Disclaimer: I've no affiliation with ruff, I just became aware of it from this discussion. Thanks heaps for that!

[frenck]

ruff seems like a complete game changer for Python linting.

Agree! I've been enjoying it myself for many weeks now, it is promising and amazing.
I hope I don't gave the wrong impression. I have been impressed and love using ruff.
Yet, in a larger project like this, I'm just more careful.

I guess a temporary shadow run for some time would be quite acceptable, it'd pave way for switching over.

Yes, I agree but didn't suggest that right away, because of the quoted part from the linked PR.

I'll add a suggestion below on the approach I would recommend.

[akx]

Glad you asked, @frenck!

Pros

• As discussed in the PR linked above, ruff is seriously blazing fast, which leads to improved developer experience and faster PR turnaround times and less cycles and energy burned (though granted, there still are very slow pylint stages, but those can be improved upon separately).
• ruff also picks up (or rather, would pick up if we let it) more problems than flake8 and the plugins currently used.

Cons

• ruff is being developed very actively, so it's a moving target. However, it seems to be stable in what it does, and new versions tend to just add new lints.

Differences in rules supported

I wrote a little script to compare the current (core @ 200d3ae845) linting rules to what Ruff supports or doesn't; please find the full analysis results over at https://gist.github.com/akx/6cd6a9e659164aecd46bdede24045592#file-home-assistant-ruff-flake8-support-md, but the main takeaways of what is not supported by ruff is below, with my comments.

• The NQA family (flake8-noqa), which analyzes that noqa comments are properly formatted, is not supported. Ruff does have the PGH family instead, which has PGH004 to ensure all noqa comments have a code attached. I think that's what matters.
  • No linting lost.
• W606, async and await being reserved in Python 3.7, is not supported. This is a non-issue for HA, since it targets 3.9+.
  • No linting lost.
• E241, E242, E502, E221, E222, E223, E224, E271, E272, E273, E274, E201, E202, E211, E701, E702, E703, E704, E121, E122, E123, E124, E125, E126, E127, E128, E129, E131, E251, E252, E231, E101, E275, W191, E261, E262, E265, E266, E301, E302, E303, E304, E305, E306, E225, E226, E227, E228, E111, E112, E113, E114, E115, E116 are all formatting-related lints from pycodestyle, which don't matter since black formats HA code.
  • No linting lost.
• W391, W291, W293 from pycodestyle are trailing-whitespace issues that are taken care of by black and pre-commit-hooks.
  • No linting lost.
• F703 is "a continue statement in a finally block in a loop". This test has been removed from PyFlakes; it can't appear.
  • No linting lost.
• D302: Use u""" for Unicode docstrings (pydocstyle). Taken care of by Black.
  • No linting lost.
• F721: DoctestSyntaxError. ruff syntax-checks doctests.
  • No linting lost.
• F831: DuplicateArgument. This is a SyntaxError anyway.
  • No linting lost.
• D401, "First line should be in imperative mood (pydocstyle)".
  • Supported as of Ruff 0.0.288 0.0.228 (implemented by yours truly).
  • No linting lost with Ruff 0.0.228.

[scop]

* `ruff` is being developed very actively, so it's a moving target. However, it seems to be stable in what it does, and new versions tend to just add new lints.

Even if they release "too often", if the existing functionality is stable enough, consumers can always choose their own update cadence. No need for a daily churn just because a new version is out, could start with something like bi-weekly. Personally I think I'll look into select = ["ALL"] and opting to ignore whatever "needs" to be separately in small projects. HA would probably be better served by a more conservative config (which is what is being suggested in the related PR).

  * Supported as of Ruff 0.0.288 ([implemented by yours truly](https://github.com/charliermarsh/ruff/pull/1999)).
  * **No linting lost with Ruff 0.0.288.**

s/0\.288/0.228/ I presume.

[akx]

numbers are hard, let's go shopping... Yes, 228.

[frenck]

That is amazing data there @akx !

And even better, the implementation/contribution of a rule ❤️

[frenck]

So, some approaches:

Approach 1:

1. Shadow run it, add it to the existing CI & pre-commit, and don't remove/change any existing things (which we can do by adjusting Introduce ruff (eventually replacing autoflake, pyupgrade, flake8) core#86224)
2. Let's see how it holds up, in a month (or maybe 2):

• Drop obsolete old tools from pre-commit autorun (manual only)
• Add ruff vscode plugin to recommended/needed extensions for dev containers
• Keep old tools still in CI

3. Let's see how it holds up now, in a month (or maybe 2):

• Drop old tools.

Approach 2:

1. Shadow run it, add it to the existing CI & pre-commit, and don't remove/change any existing things (which we can do by adjusting Introduce ruff (eventually replacing autoflake, pyupgrade, flake8) core#86224)

• Add ruff vscode plugin to recommended/needed extensions for dev containers
• Drop obsolete old tools from pre-commit autorun (manual only)
• Keep old tools still in CI

2. Let's see how it holds up now, in a month or 2:

• Drop old tools.

The difference is that 2 is a little more aggressive and quicker, but will show up quicker in dev that something is wrong. Approach 2 will allow us to deploy extra rules (provided in ruff) today, if we want.

Approach 1 is a more careful route / hold-back route.

I think either of these is acceptable.

[frenck]

Approach 2 is being implemented, thanks @akx 👍