[RFC] scripts: ci: check_compliance: Add python lint/format check

[pdgendt]

Introduction

As the codebase and contributions keep growing, so does all the python tooling.
This PR is intended to make python scripts more uniform and safe.

Proposed change

Add ruff as a linter and formatter for python files, and verify (new) files in CI.

Detailed RFC

Some hightlights:

• ruff is a drop-in replacement for many popular python tools, and it is super fast.
• The formatter output is PEP8 compliant and produces nearly identical output to black
• Can fix issues for you
• ...

Current enabled linter rules:

• flake8-bugbear
• pycodestyle
• pyflakes
• isort (black profile)
• flake8-simplify
• pyupgrade

Many more can be added/enabled but this is a solid baseline.

Concerns

Existing files do not comply, so they are explicitly excluded. Ideally these are gradually converted to comply.

$ ruff check
Found 3708 errors.

$ ruff format --check
379 files would be reformatted, 34 files already formatted

Formatting is obviously opinionated, but I do think for python we should follow the popular kids, which are black and ruff.

[nordicjm]

Why add exclusions? If someone adds a new file e.g. a runner from an external source, they would have to fix the file, but if an existing runner which does not comply is excluded, that can be updated forever going forwards without having to comply? Or is the idea that new exclusions would be added, in which case what would be the point of having the check if everything is excluded?

[pdgendt]

Why add exclusions? If someone adds a new file e.g. a runner from an external source, they would have to fix the file, but if an existing runner which does not comply is excluded, that can be updated forever going forwards without having to comply? Or is the idea that new exclusions would be added, in which case what would be the point of having the check if everything is excluded?

This is up for debate of course, but the idea is to force new files to comply, while we gradually convert the existing ones. It could be brought up during a review to update a file you are touching to comply.

[nordicjm]

Why add exclusions? If someone adds a new file e.g. a runner from an external source, they would have to fix the file, but if an existing runner which does not comply is excluded, that can be updated forever going forwards without having to comply? Or is the idea that new exclusions would be added, in which case what would be the point of having the check if everything is excluded?

This is up for debate of course, but the idea is to force new files to comply, while we gradually convert the existing ones. It could be brought up during a review to update a file you are touching to comply.

This is something I asked about before because one of the files added from an external source, a uf2 one if I remember right, had some oddities about it, and someone said the file shouldn't be fixed because whilst it was being added to zephyr, it was not a zephyr file, and you then lose the ability to diff etc.

[pdgendt]

This is something I asked about before because one of the files added from an external source, a uf2 one if I remember right, had some oddities about it, and someone said the file shouldn't be fixed because whilst it was being added to zephyr, it was not a zephyr file, and you then lose the ability to diff etc.

I think this can be an exception, but that's what the exclude lists are for.

[hakehuang]

• Can fix issues for you

can we use ruff to fix the issues in this PR?

[pdgendt]

can we use ruff to fix the issues in this PR?

Kind of chicken and egg, the check_compliance.py file itself is currently excluded because of already existing issues.

$ ruff format --check scripts/ci/check_compliance.py
Would reformat: scripts/ci/check_compliance.py
1 file would be reformatted

$ ruff check scripts/ci/check_compliance.py
Found 25 errors.

[hakehuang]

Kind of chicken and egg, the check_compliance.py file itself is currently excluded because of already existing issues.

so if this PR merged, can we then use ruff to auto fix issues? if not, this could be a heavy loading

[pdgendt]

so if this PR merged, can we then use ruff to auto fix issues? if not, this could be a heavy loading

Yes! For the current selected rules:

$ ruff check
...
Found 3713 errors.
[*] 1972 fixable with the `--fix` option (506 hidden fixes can be enabled with the `--unsafe-fixes` option).

But I'd suggest doing fixes in separate PRs to make it easier to digest for reviewing, and it's best to double check automatic fixes.

Formatting can be done too, but this would result in a lot of git churn.

[fabiobaltieri]

Seems like a good idea, curious why did you pick ruff instead of black? (I know pretty much nothing about these)

[kartben]

Seems like a good idea, curious why did you pick ruff instead of black? (I know pretty much nothing about these)

I think black is just a formatter while ruff does both linting & formatting?

[pdgendt]

Seems like a good idea, curious why did you pick ruff instead of black? (I know pretty much nothing about these)

It's all packed into one tool, so it should never contradict itself, while using different linter and formatter tools might need exceptions.
It's also super fast, and pleasant to work with. It can also be used as an LSP to get feedback directly in your IDE.