Skip to content
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

Merged
merged 15 commits into from
Aug 20, 2023
Merged

Add pre-commit #2744

merged 15 commits into from
Aug 20, 2023

Conversation

CoolCat467
Copy link
Member

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.

@CoolCat467 CoolCat467 marked this pull request as ready for review August 7, 2023 02:11
@codecov
Copy link

codecov bot commented Aug 7, 2023

Codecov Report

Merging #2744 (9978f6e) into master (4c38ba9) will not change coverage.
The diff coverage is n/a.

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           

Comment on lines 30 to 36
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
Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2023-08-08T13:55:07,201929064+02:00
case in point 😅

Copy link
Contributor

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.

Copy link
Member

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

Copy link
Member

@jakkdl jakkdl left a 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 the black and isort hooks on files not currently checked by ci.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. Running mypy -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

  • 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 Show resolved Hide resolved
.pre-commit-config.yaml Outdated Show resolved Hide resolved
Comment on lines 30 to 36
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
Copy link
Member

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.

@A5rocks
Copy link
Contributor

A5rocks commented Aug 8, 2023

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)

@CoolCat467
Copy link
Member Author

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

@jakkdl
Copy link
Member

jakkdl commented Aug 9, 2023

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)

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

@jakkdl
Copy link
Member

jakkdl commented Aug 9, 2023

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

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 check.sh. You could set checks to be default-off unless in CI for stuff that's slow or otherwise.

@jakkdl
Copy link
Member

jakkdl commented Aug 9, 2023

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)

@A5rocks
Copy link
Contributor

A5rocks commented Aug 10, 2023

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)

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

As you've noted elsewhere (w/r/t mypy trio vs mypy -m trio) the files you pass and how you pass them is important: running mypy specifically over certain files means some errors might not show up and that others might appear when they don't actually exist. (If it means anything, the stance of mypy's core devs is that pre-commit doesn't work great for mypy)

@jakkdl
Copy link
Member

jakkdl commented Aug 10, 2023

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)

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

As you've noted elsewhere (w/r/t mypy trio vs mypy -m trio) the files you pass and how you pass them is important: running mypy specifically over certain files means some errors might not show up and that others might appear when they don't actually exist. (If it means anything, the stance of mypy's core devs is that pre-commit doesn't work great for mypy)

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 mypy trio (which we might want to switch to in order to include tests and everything) and if you had your IDE configured to run type-checking (which is very common nowadays, so is a very strong argument IMO. My setup were blasting errors at me any time I had those files open). Not finding errors is of course abundant, but CI running mypy on all files will check for that.

I understand mypy not wanting to official support it (python/mypy#13916), but they do link the pre-commit mirror directly in their readme: https://github.com/python/mypy#integrations

.pre-commit-config.yaml Outdated Show resolved Hide resolved
Copy link
Member

@jakkdl jakkdl left a 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.

@CoolCat467
Copy link
Member Author

I think I'll make another PR running it on all files and fixing anything that happens once this one is merged

@jakkdl
Copy link
Member

jakkdl commented Aug 10, 2023

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?

@CoolCat467
Copy link
Member Author

Mostly just the problems with running pre-commit run --all-files that remains a stopper.

Ok so I decided to fix all the files, that's changed as of d8d6a2d

@CoolCat467 CoolCat467 requested a review from jakkdl August 14, 2023 02:49
Copy link
Member

@jakkdl jakkdl left a 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

@CoolCat467 CoolCat467 requested a review from jakkdl August 14, 2023 16:52
Copy link
Contributor

@A5rocks A5rocks left a 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

@CoolCat467
Copy link
Member Author

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)

Copy link
Member

@jakkdl jakkdl left a 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

notes-to-self/proxy-benchmarks.py Outdated Show resolved Hide resolved
notes-to-self/proxy-benchmarks.py Show resolved Hide resolved
notes-to-self/graceful-shutdown-idea.py Show resolved Hide resolved
@CoolCat467
Copy link
Member Author

To ensure this doesn't get too far out of date, I am going to merge this.

@CoolCat467 CoolCat467 merged commit bf847ec into python-trio:master Aug 20, 2023
27 checks passed
@A5rocks
Copy link
Contributor

A5rocks commented Aug 20, 2023

Mind making a followup that updates documentation on contributing to suggest this?

@CoolCat467
Copy link
Member Author

I don't mind at all, I'll be opening a new PR shortly for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants