Apply ruff formatting to the codebase

[t00sa]

@yaswant is proposing that we standardise on ruff as our linter and formatter. Testing shows that fab already complies with the linter, but changes are required to update the formatting. To minimise the impact of the change, we should:

• reformat the codebase immediately before the next release
• create a .git-blame-ignore-revs in the root of the repository and add the commit hash of the reformatting release, to ensure that git blame is continues to work as expected
• update the workflow to apply ruff as a both a linter and format checker

I suggest we adhere to the ruff/black default line length as justified in the black documentation.

[hiker]

I would throw in pylint - afaik it has more rules, and handles issues between files better (I think), see astral-sh/ruff#970 . I use pylint frequently in PSyclone, and don't consider its speed (or better: slowness) much of an issue :)

But in order to discuss the suitability of a tool, could we first get the coding style written up (as was discussed in the meeting)? The current Coding Convention page for Fab is more of a discussion about various styles, without a decision what should be done in many cases.

Imho defining the coding style should come first - once we have the coding style, we can pick the tool to use that allow us to test for the coding style. Of course, we can just say that we follow ruff style I guess, but I am not sure if ruff handles all things we want to test for. FWIW, here what we have in PSyclone:https://psyclone.readthedocs.io/en/latest/developer_guide/coding-style.html (not saying that pylint tests for all of the things :) ).

Otherwise, I am totally against applying it all at once, unless we merge all PRs in before applying it - this could otherwise create totally unnecessary conflicts in all outstanding PRs.

[hiker]

Could you add the parameters that you want to run ruff with, so we can already check all ongoing PRs to be clean? I just tried running ruff check, and that came back clean (though pylint raised an issue or two).

[yaswant]

Hi @hiker, yes, ruff check for linting and ruff format --check --diff -s --respect-gitignore for format check.

You are right: ruff and pylint have ~200 overlapping rule sets. Both have their pros and cons. Based on ruff#970, are you aware of rules that we must have currently not implemented in ruff?

[hiker]

I am actually neutral - if you ask me, I would just say what PSyclone does (pycodestyle, pylint) - but that's just because that's what I am used to :) tbh, I don't really care, so I am happy to go with whatever you (all) decide.

The one thing I like in PSyclone (and that's just a coding style rule, not enforced by a linter, though the CI verifies some requirements):

1. Any modified line in a PR must be covered by a test (that's tested by the CI I think).
2. A file a/b/c.py has a matching test file: tests/a/b/c_test.py, and just executing this test should cover the file by 100% (or as much as possible, e.g. type checking if's are difficult).

While this can be annoying, it just means if you modify a file, you can get at least a very quick first consistency test by running a single test file (in PSyclone we have >5000 tests, plus system tests that run for something in the order of hours).

So, I am happy using ruff (or whatever), but would really say that we need proper coding styles. I often find myself not sure if I should flag things (that I think are important, but are actually only coding style, and are not covered).

[hiker]

@yaswant , I'd say now after the 2.0 release is a good time to bring this in, so I've marked this for 2.1.

[t00sa]

We agree that this is a good thing. We will schedule this for a time when there are limited numbers of open PRs. We will add a checking workflow and enforce after the change. @MatthewHambley and @yaswant to discuss setting this up.