-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Apply and ensure Black formatting #1101
Conversation
So am I correct in saying that this doesn't actually auto-format the code, it just marks PRs as unsuccessful (and therefore unmergable) if they fail? |
@tburrows13 yes, you are right. |
well, I don't know why the git action didn't run. It was automatic when I tried this on my fork. Anyway, should be ok after merge. |
And I'm wondering if wouldn't be better to implement #1081 first, removing old python version from the CI matrixes, and apply this targeting directly py36. So, we don't need another PR to apply a new black rewrite. |
I agree, I intend to start a new branch today for v2.0 that removes all py27 testing. Then we can merge PRs like this one into it. |
A bit later than expected, I've created #1103. When #1103 is merged into the v2 branch, you can update this PR with a fresh run of Black (without worrying about Py2.7, and then we can merge this in before anything else is merged). I think adding something into the 'Standard workflow' in Also I think the name 'sanity checks' is not very descriptive. How about 'Code Format Check' or something like that? |
@tburrows13 update done. |
Thanks for this. I'm happy to merge now. |
Fix for #1097