In RFC-162 we determined the set of PEP8 exclusions that are implied by our existing DM Python Style Guide (thanks @parejkoj, @timj and @frossie!). As @rowen noted, now that we can use linters in our editors for DM python code (and soon we’ll have automated linting of pull requests), there is a large amount of technical debt associated with giving our codebase a clean PEP8 checkout. At this point, PEP8 fixes must be made before any new code can be merged.
autopep8 gives us a way of fixing PEP8 issues against the DM Style Guide:
autopep8 . --in-place --recursive \
--ignore E133,E226,E228,E251,N802,N803,W391 \
--max-line-length 110
Given the large number of DM GitHub repos, we can take this automation one step further. In sqre-codekit we developed the infrastructure to clone all DM repos, make and commit code changes, and push those changes to a new branch from a single command. I’ve extended codekit to run autopep8:
lsst-autopep8 -u jonathansick --org lsst --team 'Data Management' \
--branch tickets/DM-NNNN
(alternatively you can run lsst-autopep8
for a single repo with a --repo
argument).
See the code at https://github.com/lsst-sqre/sqre-codekit/pull/3.
An example of what autopep8 does to LSST repos can be found in the https://github.com/jonathansick-shadow test organization (see u/jonathansick/autopep8
branches; here’s afw in particular: https://github.com/jonathansick-shadow/afw/commit/660287ac88f56b5a8e0b506364b3845611f2962c)
Given this:
- Do we want to take an automated approach to fixing our PEP8 technical debt? If so,
- What is the best way to coordinate the execution of
lsst-autopep8
so that there are as few merge conflicts as possible for those with existing tickets in these repos?
Note that lsst-autopep8
only creates a new branch with PEP8 fixes; a manual merge step is still required. One can even imagine pushing additional formatting changes to the branch after autopep8 has done the initial work.