chore: switch to ruff format
over black
#765
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We've had both
black
andruff
making changes to the code on lint/pre-commit for a long time.Ruff now claim that their formatter is a drop-in replacement for
black
.This PR switches
make format
from usingblack
to usingruff format
.The rest of the diff is the result of running
make format
on the code after the switch, which look like only line length changes.When we had
black
andruff
, both had a line-length setting, and black was set to 130 but to ignore some files, and ruff was set to 150 but to ignore no files. Inruff format
, there's no way to set the line length to be different for linting and formatting, so some lines are changing from 130 to 150. So there used to be some files with a 130 line length limit and some files with a 150 line length limit. Now all files are at 150.We could also standardize on 130. I'll defer to whatever the team wants here.
Also,
black
used to allow (require?) a blank line betweenclass Foo:
and__some_var__ = whatever
.ruff format
by default takes this line out. I haven't figured out a way to tellruff format
to allow this, so these blank lines are going away.The total speed up benefit of this is not as much as I'd hoped -
make static-analysis
is pretty variable in how long it takes, but it seems between 200 and 500 millis faster on this branch, out of a total of about 4000 millis, so about maybe 10% faster). Still, this gets run a lot, so a small speed-up is welcome.I think the real benefit is having only one tool that care about line length. Having a list of strings as exclude paths instead of a multi line regex is nice too.