This is actually nice. The difference in speed is noticeable.

Thank you for this PR!
Let's say there is an appetite for this particular change.
For the PR to be merged, though, there would be a few things to take care of, please let me know if you are happy to take them on:

1. Ensure a 1-1 correspondence between the current settings and the new ones with ruff. In his case, the command introduces a line length limit of 117 whereas this project explicitly disables line length checks currently. Generally, these changes should not be introduced without mentioning them explicitly.
2. Run the command on the repo and contribute also the changes that will fix violations. In his case, two violations appear, and this would result in an immediate CI failure upon merging this PR.
3. Also change non-functional code that refers to the changes you are making. There is a title for the step you are changing that refers to flake8 and should not. But also there are other places in the repo that refer to the tools you are replacing, like the dev.requirements file and the format.sh script

this project explicitly disables line length checks currently

Disabling line length checks (and code complexity checks) is a bad idea because it encourages further bad behavior. If instead we set an upper limit then if someone wants to contribute longer lines (or more complex code) then they need to justify in their pull request why they need messier code then is already in the codebase.

contribute also the changes that will fix violations

Rome was not built it a day. A pull request that improves the codebase by setting up guardrails moves the project forward. Fixing the two ignored issues will make for a much more complicated pull request to get reviewed and merged. Given that this pull request has taken more than 5 months to get reviewed, keeping the changes simple is goodness.

other places in the repo that refer to the tools you are replacing, like the dev.requirements file and the format.sh script

This GitHub Action does not use dev.requirements and ruff is not a code formatter. Black is.

Contributors/Collaborators - Please feel free to approve and merge.

One question: Do we need to ensure 'ruff' is installed on all systems without it being in the requirements.txt

Do we need to ensure 'ruff' is installed on all systems without it being in the requirements.txt

Perhaps ruff and black and similar tools should be run in pre-commit to ensure the same versions are installed on all contributing and testing machines.

Fixing the two ignored issues will make for a much more complicated pull request to get reviewed and merged.

My bad, I did not mean the ignored issues, but it was a misunderstanding coming 100% from me. My working tree was dirty, and the command caught some errors in some experimental test files I had around. No real issues here.

Given that this pull request has taken more than 5 months to get reviewed, keeping the changes simple is goodness.

Regardless of the misunderstanding, I believe the time it takes to review PRs here depends more on the availability of the maintainers than on anything else.

Do we need to ensure 'ruff' is installed on all systems without it being in the requirements.txt

I would add a line to the dev.requirements.txt, with a specific version, and I think this PR would benefit from locking on the version of ruff in the workflow file too.

RE: the line length check. I'm all for it and this could then be the last time two humans have a conversation about such a boring topic on this repo 🥂 .

@jdevera, I merged this in, but CI wasn't happy with it, and I didn't have time to investigate. I've reverted it for now.

I believe adding feat/* and bug/* to the GitHub action would be beneficial. This way, any push to such a branch would trigger CI, allowing us to know if CI fails before any PR is created.

Had these changes been in feat/flake-ruff, a GitHub action would have been triggered.