ci: replace Python linter flake8 with ruff

[cclauss]

Ruff supports over 500 lint rules and can be used to replace Flake8 (plus dozens of plugins), isort, pydocstyle, yesqa, eradicate, pyupgrade, and autoflake, all while executing (in Rust) tens or hundreds of times faster than any individual tool.

The ruff Action uses minimal steps to run in ~5 seconds, rapidly providing intuitive GitHub Annotations to contributors.

@nschonni

[nschonni]

I'd suggest copying the filters from https://github.com/nodejs/build/pull/3301/files#diff-14721317565b7c66355f276ec27762054b12f390afd6c35fba85cfaf77d311c7R2, but adding pyproject.toml to the lists

[cclauss]

This is a bad practice when tools are fast.

build git:(ruff) % time ruff .

ruff .  0.01s user 0.03s system 74% cpu 0.065 total

Ruff will lint the entire CPython codebase in 0.29 seconds with no cache so we are saving no time by attempting to hide files from the linter and could easily miss faults in code added to this repo in the future.

[nschonni]

It's not about tool speed, it's about not running jobs that can have unrelated job failures on a PR

[nschonni]

Are this ignores TODOs or forever things? Sometimes useful to document why/how the might be fixed if someone has an interest to try and address them later

[cclauss]

I will let others determine if/when they want to reduce the ignore list

Rule information is easy to acquire: ruff rule B904

raise-without-from-inside-except (B904)

Derived from the flake8-bugbear linter.

Message formats:

• Within an except clause, raise exceptions with raise ... from err or raise ... from None to distinguish them from errors in exception handling

[nschonni]

If the target is going to stay 3.7 for now, maybe the CI should keep the pinned version that I dropped in the other PR

[cclauss]

See #3301 (comment)

Ruff does not run on Python so it changes in similar ways to flake8 but only based on --target-version=pyXX.

Just like Node.js, Python has a release cycle: https://devguide.python.org/versions

Py37 will reach EOL in two months.

[nschonni]

Guessing this was to get it passing, rather than a preferred line length like the old 250 value

[cclauss]

88 is the preferred value for Python code. The goal here is to set high water marks so that if a contributor wants to go beyond that level they will need to justify their actions in the code reviews of their pull requests. The same is true of max-args, max-branches, max-complexity, etc.