python: reformat and addition of format checks #1802
Conversation
|
Hilariously, IMO, the formatter used by pylint generates code that fails pylint. I will adjust our settings so the checks match the formatting. |
Codecov Report
@@ Coverage Diff @@
## master #1802 +/- ##
==========================================
- Coverage 80.12% 80.11% -0.02%
==========================================
Files 196 196
Lines 35064 35064
==========================================
- Hits 28096 28092 -4
- Misses 6968 6972 +4
|
There was a problem hiding this comment.
Thanks for putting this together, @trws!
Can we add check-format as one of the MAKECMDS in travis_run.sh so that Travis will turn red if the formatting is incorrect? A more extreme option would be to create a separate test within the travis build matrix, like Spack has.
src/bindings/python/.pylintrc
Outdated
| @@ -44,7 +44,7 @@ symbols=no | |||
| # --enable=similarities". If you want to run only the classes checker, but have | |||
| # no Warning level messages displayed, use"--disable=all --enable=classes | |||
| # --disable=W" | |||
| disable=missing-docstring, too-few-public-methods, too-many-arguments, star-args, arguments-differ, no-member, import-error, no-name-in-module, useless-object-inheritance, fixme | |||
| disable=missing-docstring, too-few-public-methods, too-many-arguments, star-args, arguments-differ, no-member, import-error, no-name-in-module, useless-object-inheritance, fixme, C0330 | |||
There was a problem hiding this comment.
Do you happen to know what the "human-readable" code for C0330 is? If so, can we use that instead? Based on this issue, I believe it is bad-continuation.
|
Definitely, I want this check to be part of travis, and I want this and pylint to run first rather than last as is being done now. There's little more frustrating than compiling, checking and passing everything only to run the format check and fail at the end. 😖 |
I think we agreed that C should be a separate PR/issue. In addition to this, we should probably also add a python section to RFC 7 to document our practices/expectations for people submitting PR's to framework projects. Sounds like it can just reference the the Black code style instead of the specific details, if we are happy with that style. |
|
I have a locally rebased version of this waiting on #1795, having outstanding python PRs during a reformat would be unfortunate, should be very quick once the other merges. |
|
@trws, I'm adding this to the 0.11.0 release milestone per your comments yesterday. |
garlick
changed the title
trws
force-pushed
the
format-checks
branch
4 times, most recently
from
1dbafa1
to
ed1bae7
Compare
|
Ok, this includes formatting of all the python code, rebased on current master, with a new build stage setup in travis so that the main builds wont even try to run unless the style checks pass (faster feedback for the thing that's quick to check, less wasted build cycles, etc.). Assuming the currently running travis build passes, this should be GTG. |
|
Travis passed, but apparently codecov/project did not. I'm not sure what to do about that given that this PR didn't actually add any new code (except the check script). Perhaps it doesn't like that the code is now on more lines? |
|
Thanks @trws! Other than the pylintrc comment above and some commit polishing, this LGTM! I wouldn't worry about the codecov since it doesn't track python files. Per the commit polishing, before merging, it would be good to squash some of the incremental commits and reword the commit titles to the form |
|
Thanks @SteVwonder, the commits have been re-worked, and the bad-continuation option seems to work. Assuming I didn't muck something else up and the rest of the travis run passes, we should be GTG. |
|
I think that last commit could be squashed with the first one. Making this a separate stage in travis looks really nice in the ci summary page! @grondo could you give your ack on the travis changes? |
|
Oh yeah, Travis changes look great. Thanks, @trws! |
|
Good point, squashed and re-pushed. |
|
Restarted a builder that failed the wreck epilog test. Apologies @trws, this needs one more rebase then I'll press the button. |
ignore badly considered continuation check in pylint, set line-length to 88
check-format: fix pipe error
|
Thanks! |
Currently this applies the "black" formatter to our python code globally and adds two scripts, one that runs it to format all python code int the tree and another that checks whether formatting would change the code. I'm planning to have the check script run in at least one of the travis targets, probably along with pylint.
The question now, is should I also add the clang-format formatting for our C code to this. It's not materially harder, but before I do it, we need to pick a standard version to use (I suggest 6.0 or 7.0) and agree that the format file as defined in this PR (same as we had but disregarding support for 3.6, which is now ancient) is what we want code to look like or modify it such that it is. Thoughts?