-
-
Notifications
You must be signed in to change notification settings - Fork 8.5k
[py]: Introducing code formatting for a consistent code base #10761
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
Conversation
Codecov Report
@@ Coverage Diff @@
## trunk #10761 +/- ##
=======================================
Coverage 52.24% 52.24%
=======================================
Files 84 84
Lines 5482 5482
Branches 272 272
=======================================
Hits 2864 2864
Misses 2346 2346
Partials 272 272
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
- If tox exits `0`, commit and push otherwise fix the newly introduced breakages. | ||
- `flake8` requires manual fixes | ||
- `black` will often rewrite the breakages automatically, however the files are unstaged and should staged again. | ||
- `isort` will often rewrite the breakages automatically, however the files are unstaged and should staged again. |
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.
should be
staged ...
I'm rolling this out gradually with a |
This makes some improvements to the python linting, Moving forward I would like to get the entire code base linted in a consistent manner for ease of maintenance and contributions.
As a proof of concept this pull request contains the following:
tox -e linting
recipe.Black
(very common python code formatter) enablement only on/py/test/*
to prove things out.Isort
- Python import automatic sorter and managerflake8
work in tandem withblack
&isort
.git-blame-ignore-revs
file for assistinggit blame
with sweeping changes required in future.Keeping things small and incremental right now to allow things to roll out gradually.
I would much rather have pre-commit implemented with this - why?edit: I know you all hate the idea of pre-commit 😄git commit <...>
, enforcing client side compliance, the argument for not wanting it to get in the way is trivial,--no-verify
works as normal ANDSKIP=HOOKNAME git commit <...>
gives individual hook skips!.git/hooks
its all implicitI have kept this over
py/test/
for now, but I would really like to have it fully rolled out, the benefits are fantastic (imo).Right now as-is the flow is unchanged, what once was
tox -e flake8
should now be run astox -e linting
is now much more thorough and automatic at finding and correcting code formatting, this makes at most very minor changes to the underlying AST/BC so will not introduce any bugs into the code.