-
Notifications
You must be signed in to change notification settings - Fork 615
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
Enabling black progressively. #932
Conversation
python -m black ./ | ||
python -m flake8 |
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.
So at some point I would like to have this down to a single check. Once the rather large black reformatting is complete do you see a need for flake8? I believe as a subset of pep8 we should be fine (minus the line length)
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.
Flake8 is an addition of multiple tools. If we enforce black, then we should disable pycodestyle. See http://flake8.pycqa.org/en/latest/user/error-codes.html
I'd preferto use flake8 with pycodestyle disabled. We get useful checks and we can add plugins to flake8 in the future.
I'll disable pycodestyle in another pull request if you don't mind :)
If we want one single check, I can look into how to put everything in a bash script/docker command/pre-commit hook.
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.
LGTM! We can start formatting our code with some care to not stomp on on-going pull requests
# Ignore all hidden files | ||
.* | ||
|
||
# Include travis.yml | ||
\!.travis.yml | ||
\!.flake8 |
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 think it's okay to allow hidden files. If we see this as an issue we can revisit. It was a larger issue before when we were planning on doc files living within the repo that were auto generated.
With this method, we have a big todo list and we can start formatting files with black when there are no pull requests pending and working on those files.
Hooo boy this pull request was painful. Lesson learned, pre-commit and customization don't play well together.
I removed the exception for dotted files in the gitignore because it didn't work to just write: