-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to ruff / Add pre-commit hook #4428
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neat! Definitely caught a few subtle bugs/issues here, thanks for introducing the linter! I even learned some more python syntax I wasn't even aware of!
Personally I don't mind the empty f-strings, and I doubt they really affect performance much. But I guess good to get rid of either way.
app/backend/src/couchers/migrations/versions/bf12729fa8eb_sms_verification_constraints.py
Outdated
Show resolved
Hide resolved
app/backend/pyproject.toml
Outdated
ignore = [ | ||
"B007", # Loop control variable not used within loop body | ||
"E501", # Line too long | ||
"E711", # Comparison to `None` should be `cond is None` | ||
"E712", # Avoid equality comparisons to `True`; use `if approved:` for truth checks | ||
"F811", # Redefinition of unused variable | ||
"F841", # Local variable is assigned to but never used | ||
"UP015", # Unnecessary open mode parameters | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this still an accurate list? These linters rules seem useful, are we failing a lot of them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So after looking at the code these are checks that I excluded for the following reasons, correct me if I am wrong:
- B007: Sometimes we might want to have the variable unpacking to make clear what is being iterated over, no? As in
for topic, name, items in group:
, even if we just use topic/items? - E501: Would need quite a bit broken up or marked as noqa, as it also considers comments and long strings
- E711: We use None to compare to sqlalchemy results - Correct me if I'm wrong, but I think these are not actually
None
, but just falsy? - E712: Same as above, just for
True
- F811: This currently applies to all fixture usages. We could fix this by not importing fixtures but having them in a
conftest.py
file - F841: This I assumed often refers to things that are in a variable that might be valuable later on, so I did not want to remove them all
- UP015: Personal opinion, but I like to be excplicit about the open-mode
For each rule, you can comment out the ignore-line and check which lines would be affected to see for yourself as well. I think for F841
especially, you will be able to judge better what to exclude and what to leave.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To B007
: You can put an underscore in front of the variable that is not required, but named. E.g: for topic, _name, items in group:
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@HansBambel Just saw that you commented, great to see you here 😄
These are current files that are over 350kb - I guess most of these are fine, but maybe good to have an eye on it.
|
At some point, we could also integrate This formatted the files, but always fails with an error "No such file or directory", so I left it out for now.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you addressed all my questions. Looks good to me now!
# Conflicts: # app/backend/requirements.txt
@aapeliv I merged develop into the branch, ready to be merged once you approve it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, please merge!
I really like this... it's so friggin fast xD |
* Switch to ruff and applied linting rules * Add pre-commit and apply hooks to all files; Added ruff configuration to media and client * Restrict ruff pre-commit hook to only the backend * Adjusted pull request checklist template * Fix set error * Implementing of code review findings; Fix of further lint findings * Remove check-json from pre-commit; Applied clang-format * Fixed requirements.txt
I switched from black/isort/autoflake to ruff, which is much faster, combines these tools and also is a strong linter. Additionally, I set up a
pre-commit
hook that can optionally be used to enforce QA-checks before each commit. I personally find it very satisfying to work with this, as it often corrects/spots smaller errors.I exclude stricter linting rules that might limit our development style, but applied multiple other linting rules which I think are sensible.
ruff linting modules that I normally use but omitted for now are pydocstyle ("D") and mccabe complexity ("C90"), as some functionality would need to be refactored to reduce complexity in our case and enforcing doc strings everywhere might also be quite restrictive.
Backend checklist
ruff check --select I --fix . && ruff check . && ruff format .
inapp/backend
develop
if necessary for linear migration history