Switch to Ruff & set up pyright (opt-in)#16
Conversation
* Swap out isort/black/flake8 for ruff * Add placeholder to suggest type checking * Updated the used github actions to their latest versions * Updated default python/django support matrix (include Django 5.2, start from Python 3.12)
sergei-maertens
requested review from
stevenbal,
svenvandescheur and
swrichards
| paths: | ||
| - '**.py' |
There was a problem hiding this comment.
Removed this as I've had plenty of cases where config changes lead to the CI checks not running and the next one doing code changes has to deal with the broken config from the previous contribution.
Ruff is fast enough, there's no reason to not just always run these checks.
| extend-select = [ | ||
| "UP", # pyupgrade | ||
| "DJ", # django | ||
| "LOG", # logging | ||
| "G", | ||
| "I", # isort | ||
| "E", # pycodestyle | ||
| "F", # pyflakes | ||
| "PERF",# perflint | ||
| "B006",# flake8-bugbear | ||
| "B010", | ||
| "B904", | ||
| ] |
There was a problem hiding this comment.
picked the config from OIP/django-upgrade-check, @swrichards is working on a nitpick solution to keep those in sync/centralized
sergei-maertens
force-pushed
the
chore/switch-to-ruff
branch
from
7b6ba2e to
0f62631
Compare
In general I don't see any compelling reasons against going all-in on ruff (beyond the well-known VC rug-pull concerns, which it seems to me are adequately addressed due to the licensing structure), and specifically for the starter template I think we can be a bit more ambitious as to the scope of the rules. The guiding principle I think would be to identify rules that don't fall into the "reasonable people can disagree" column: for instance, the I think this ruleset is fairly balanced in this regard. On the style end of the spectrum the Django, isort and python-next rules make sense to be me as style-focused but non-optional (Django and isort for cross-project readability, python-next because adapting to the latest language idiom should be a standing goal). Bugbear, perf, logging and the like point mainly to things which are most of the time undesirable patterns and potential errors, to the extent that making them mandatory seems sensible. It might well be the case that the rule classes include individual rules that are cumbersome or unhelpful, but it's hard to get a sense of which without unleashing this on a large code base. I think it would not be a problem if individual projects have opt outs for individual rules (and any tooling around this would permit that) though, so if this is encountered, the Note that bringing existing projects up to scratch with this list is no small undertaking, but that's a separate discussion. |
* Added Ruff linter configuration * Replaced isort config with Ruff isort plugin * Removed flake8 config * Added pyright config (opt-in)
sergei-maertens
force-pushed
the
chore/switch-to-ruff
branch
from
0cd54b3 to
46defa8
Compare
* Replaced black, isort and flake8 envs with a single ruff env * Ruff outputs in a format that can be picked up by Github actions for actual code annotations. * Added env for type checking with pyright, deactivated by default.
sergei-maertens
force-pushed
the
chore/switch-to-ruff
branch
from
46defa8 to
5fa04ef
Compare
It's replaced by the raw make calls in tox.ini which provide better to parse output anyway.
sergei-maertens
force-pushed
the
chore/switch-to-ruff
branch
from
5fa04ef to
783f1df
Compare
3 participants
After the consensus among the team :)