You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently use flake8 for our linting. There's nothing wrong with that, but ruff is a lot faster, as well as being a single tool rather than one tool plus some (independently maintained) plugins.
The set of warnings is going to be slightly different (ruff doesn't claim to implement everything included in the various plugins it copies) but I'm not sure we care as long as the results on the current codebase are the same - I don't believe anyone ever audited the full list of checks currently applied1, our style rules are basically just "must pass the tools we use in our standard linting config". On which basis, changing the linter seems perfectly acceptable.
Describe the solution you'd like
Replace our existing flake8 configuration with ruff. We could also use ruff in place of isort, further simplifying our setup.
Alternative Solutions
Stick with what we have. It's not as if there's a great need to change.
To be clear here, I'm not pushing for this, I'm raising this mostly just to get a feel for what others think of the idea.
Additional context
I did some experimenting, and the following addition to pyproject.toml seems to replicate what we have for flake8.
src\pip\_internal\network\auth.py:517:9: B018 Found useless expression. Either assign it to a variable or remove it.
tests\lib\__init__.py:687:39: B026 Star-arg unpacking after a keyword argument is strongly discouraged
To be honest, both seem legitimate (although it's a matter of opinion whether we should fix or ignore them, I don't really have a preference) and I'm not clear why flake8-bugbear doesn't flag them - I couldn't see any indication that they are disabled by default.
Also, as a result of globality-corp/flake8-logging-format#68, I expect our current lint setup to start failing on Python 3.12 (I first started thinking about using ruff because I hit that problem locally, as I configure virtualenv to omit setuptools and wheel by default).
I'm a big fan of Ruff, I will point out a couple of things to be aware of:
Last I checked parsing stack is based on RustPython which uses an LL(1) parser rather than a PEG parser, this can lead to them to implementing new syntax rather slowly. E.g. match statement syntax has only been supported since February 2023 even though it had been in Python since October 2021.
Also Ruff is relatively new and may be missing edge cases. E.g. I discovered recently it's scoping rules inside comprehensions inside class scope was wrong (I found this as I was testing PEP 709 discussion), I reported and the author was was very quick to fix.
Neither of these things I think should significantly affect Pip, but something to be aware of.
What's the problem this feature will solve?
We currently use flake8 for our linting. There's nothing wrong with that, but ruff is a lot faster, as well as being a single tool rather than one tool plus some (independently maintained) plugins.
The set of warnings is going to be slightly different (ruff doesn't claim to implement everything included in the various plugins it copies) but I'm not sure we care as long as the results on the current codebase are the same - I don't believe anyone ever audited the full list of checks currently applied1, our style rules are basically just "must pass the tools we use in our standard linting config". On which basis, changing the linter seems perfectly acceptable.
Describe the solution you'd like
Replace our existing flake8 configuration with ruff. We could also use ruff in place of isort, further simplifying our setup.
Alternative Solutions
Stick with what we have. It's not as if there's a great need to change.
To be clear here, I'm not pushing for this, I'm raising this mostly just to get a feel for what others think of the idea.
Additional context
I did some experimenting, and the following addition to
pyproject.toml
seems to replicate what we have for flake8.There are two warnings remaining:
To be honest, both seem legitimate (although it's a matter of opinion whether we should fix or ignore them, I don't really have a preference) and I'm not clear why flake8-bugbear doesn't flag them - I couldn't see any indication that they are disabled by default.
Code of Conduct
Footnotes
Much less review each new linter release to decide if we like whatever gets changed 🙂 ↩
The text was updated successfully, but these errors were encountered: