-
-
Notifications
You must be signed in to change notification settings - Fork 301
Add pre commit integration #216
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 @@ ## master #216 +/- ## ======================================= Coverage 95.64% 95.64% ======================================= Files 34 34 Lines 942 942 ======================================= Hits 901 901 Misses 41 41
Continue to review full report at Codecov.
|
I very much prefer format
(like fastapi) instead of reformat
which feels redundant.
I'm not sure about adding pre-commit Lee. It will be an entry barrier, and it's not adding much. It will be a pain-point during the sprints.
From my perspective:
- Our CI catches lint and test errors just fine.
- We don't make mistakes often when creating PRs to justify pre-commit.
- We can squash commits from contributors if they don't match conventional commits.
What do you think about it?
I very much prefer
format
(like fastapi) instead ofreformat
which feels redundant.
I totally agree with it 😄
I'm not sure about adding pre-commit Lee. It will be an entry barrier, and it's not adding much. It will be a pain-point during the sprints.
From my perspective:
* Our CI catches lint and test errors just fine. * We don't make mistakes often when creating PRs to justify pre-commit. * We can squash commits from contributors if they don't match conventional commits.
What do you think about it?
I agree with your points of view but also like pre-commit 😆. I don't have a strong option on whether to use pre-commit after reading your comments. Here's my thought on why using pre-commit might be good and might not be a huge entry barrier. 🙂
- pre-commit is optional. We're not able to force contributors to install it when they're to contribute. It's a kinda helper for them to meet our requirements. But even if they don't, we could still handle it as you said.
- As a contributor, I like to learn best practices from contributing to open source projects, especially in a sprint. (I actually learn a lot from this project) Even if the contributors run into a problem, I don't think it will take to much of our time to instruct them during the sprint.
- As a maintainer, it can save some of our time to do those trivial kinds of stuff.
You are right, but everything we add adds more maintenance, plus what's the point of the extra noise if not used?
I remember my first contributions/projects and there were things there were super confussing and I was lost in a sea of questions haha (specially with tox).
But okay, If you think it will really add value to us, I'm in for it, we can try it (worst case if we feel like it's not adding value, we can remove it as it's not part of the src code).
Yes, I think it will add value to us. 🙂 But I also understand your concern. We can test it in euro python 2020 sprint and pycon tw 2020 sprint (I will host one in Taiwan 🇹🇼) to see whether we will encounter the problem you mention. I'll merge it for now.
(Thanks for sending a pull request! Please fill in the following content to let us know better about this change.)
Types of changes
Please put an
x
in the box that appliesDescription
Add pre-commit config and fix styles through it
Checklist:
./script/reformat
and./script/test
locally to ensure this change passes linter check and testSteps to Test This Pull Request
pre-commit install # make some change cz commit git push ...
Expected behavior
./script/reformat
and./script/test
when pushingRelated Issue
#211
Additional context
image