-
-
Notifications
You must be signed in to change notification settings - Fork 344
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
Add pre-commit #2744
Add pre-commit #2744
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #2744 +/- ##
=======================================
Coverage 98.92% 98.92%
=======================================
Files 113 113
Lines 16728 16728
Branches 3026 3026
=======================================
Hits 16548 16548
Misses 124 124
Partials 56 56 |
.pre-commit-config.yaml
Outdated
ci: | ||
autofix_commit_msg: "[pre-commit.ci] auto fixes from pre-commit.com hooks" | ||
autofix_prs: true | ||
autoupdate_commit_msg: "[pre-commit.ci] pre-commit autoupdate" | ||
autoupdate_schedule: weekly | ||
skip: [flake8] | ||
submodules: false |
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 don't think we want pre-commit CI (other than maybe for updating the pre-commit hooks). We're intentionally not pushing commits based on what autoformatters want since that might interfere with an WIP PR, for instance.
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.
Running Black on WIP PR's should not be a problem. isort
could in theory be a problem, but I suspect it'd help more often than it hurts - and in any case it doesn't modify your local repo and you can review the commit before isort
does its thing if you want.
But it can definitely be messy, it's probably a tradeoff between experienced contributors (that will have taken the decision whether to run the pre-commit hooks locally) vs new contributors (that might struggle with setting up tooling and will waste time doing several CI runs until stuff passes) and people maybe having to review unformatted code.
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.
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.
Yeah I keep using the web editor for small changes :(
I do think for larger PRs changing the code from under their feet is a bit annoying.
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.
using the web editor seems like a strong case in favor of it. Leaving it off at the beginning seems reasonable regardless just to make sure it works and all, and then we can try toggling it later
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.
-
Yeah I've been thinking about this in Use tox and/or pre-commit for static analysis checks #2699 and created a
.pre-commit-config.yaml
for personal use myself. -
pre-commit run --all-files
will trigger a lot of changes in theblack
andisort
hooks on files not currently checked byci.sh
. Either ignore these or reformat them (in this or another PR). Flake8 also complains about a couple files -
You're missing
codespell
-
We probably want mypy in this once one can run
mypy .
without triggering errors. Runningmypy -m trio -m trio.testing --platform=x.y.z
should be possible, but clunky and slow -
If the long-term plan is to replace
ci.sh
(which I'm strongly in favor of) you also want the ability to run_tools/gen_exports.py
_tests/_check_type_completeness.py
or at leastpyright --verifytypes
(on all platforms) once that passespip-compile -q ...
... except good luck doing that withouttox
to manage python version, but there's discussion in python version for CI formatting check #2681 and there's Rework packaging to use Poetry instead. #2595- Several of these should probably be default-off though
-
I personally also have
autoflake
enabled -
I've had
https://github.com/macisamuele/language-formatters-pre-commit-hooks
--pretty-format-toml
enabled for this repo, but dropped it at some point for some reason.
.pre-commit-config.yaml
Outdated
ci: | ||
autofix_commit_msg: "[pre-commit.ci] auto fixes from pre-commit.com hooks" | ||
autofix_prs: true | ||
autoupdate_commit_msg: "[pre-commit.ci] pre-commit autoupdate" | ||
autoupdate_schedule: weekly | ||
skip: [flake8] | ||
submodules: false |
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.
Running Black on WIP PR's should not be a problem. isort
could in theory be a problem, but I suspect it'd help more often than it hurts - and in any case it doesn't modify your local repo and you can review the commit before isort
does its thing if you want.
But it can definitely be messy, it's probably a tradeoff between experienced contributors (that will have taken the decision whether to run the pre-commit hooks locally) vs new contributors (that might struggle with setting up tooling and will waste time doing several CI runs until stuff passes) and people maybe having to review unformatted code.
FYI mypy shouldn't be used as a pre-commit hook. (The whole point of pre-commit hooks is to run checks on some subset of files and yet mypy should really check all files) |
Personally I think the best thing to do is have pre-commit do auto-fixes and actual github actions do the tests that don't have auto-fixes or things that shouldn't be auto-fixed |
I personally very much like running mypy locally as a pre-commit hook to catch small type errors before I push, and only running it on a subset of files speeds it up so so much. But of course CI should check all files to catch errors introduced in other files |
hm, I personally like it for any check that's quick to save you having to wait for a failing CI. Esp as pre-commit will limit the subset of files it checks so it's much much faster than running them manually locally as well unless you set up something fancy. Esp something like codespell I see no reason at all not to put in pre-commit I also think there's a strong case for having all checks configured and run from the same place, parsing the output of pre-commit is much better than digging into the text log of |
For reference, this is the config I've crafted for flake8-trio: https://github.com/Zac-HD/flake8-trio/blob/main/.pre-commit-config.yaml (most of the flake8 checks are redundant since the addition of ruff though - but I've been keeping them just to see if they ever disagree) |
As you've noted elsewhere (w/r/t |
The only issue I've hit with false-positives so far is on files that were conditionally imported on different platforms, but that was easily resolved with adding platform type guards to the files. This wasn't isolated to pre-commit though, it also happened with I understand |
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.
Mostly just the problems with running pre-commit run --all-files
that remains a stopper.
I think I'll make another PR running it on all files and fixing anything that happens once this one is merged |
can maybe ignore/exclude the files for now? |
Ok so I decided to fix all the files, that's changed as of d8d6a2d |
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 avoid another #2711, I think subdirectories under docs/source
should be ignored. And not just a matter of updating references to them now, as I think extra empty lines from isort or black is quite unnecessary in those short examples.
This should be set in pyproject.toml
(for both isort and black) so they're ignored by manual runs as well. To still get fixes in conf.py
and local_customization.py
the easiest is probably to explicitly list the three subdirectories.
reformatting notes-to-self shouldn't be a problem afaik
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.
Just a reminder about #2744 (comment) :P
Disabled black and isort for CI autofixes in 316838a (though I do hope we will turn that on) |
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.
just a couple small nits
To ensure this doesn't get too far out of date, I am going to merge this. |
Mind making a followup that updates documentation on contributing to suggest this? |
I don't mind at all, I'll be opening a new PR shortly for that. |
Up for debate, but I find pre-commit auto-formatting code for my own projects very useful, and thought I would suggest trio adopting it as well.
Basically pre-commit uses git's hooks system to do anything you want it too, all defined from one file. They have more information about it on their website (https://pre-commit.com/).
They also have a continuous integration system (more info at https://pre-commit.ci/) that means you can do things like automatically doing things like code formatting on pull requests and committing directly.
This PR adds the config file pre-commit looks for, and has pre-commit do black code formatting and isort, as well as flake8, but I'm not super sure about that because sometime I plan to make another PR for moving over to use ruff instead, so it's skipped in the ci run section currently.