Adding code formatter/linter to workflow?

[karlding]

What are your thoughts on enforcing automated formatting across the project? With various people contributing code, ensuring that consistent code style is followed is always a challenge. This often adds noise to PRs, and just is another thing for PR reviewers to worry about.

An automated formatter (I like black due to the lack of configuration options it exposes, but that's just my preference) would automatically format code so that all code is formatted consistently. This can also run in CI to ensure that commits have been formatted correctly before merging.

It'll probably cause a lot of conflicts with currently open PRs (and cause 1 giant diff of a commit), but maybe it's worth considering. And if this is adopted, the format can be done incrementally before flipping the CI checks to reduce the amount of pain with open PRs.

Similarly, what are your opinions on adding a linter (pylint, flake8, pycodestyle, etc.) to the workflow? An incremental approach could be taken to slowly make things comply with whatever rules are chosen.

[hardbyte]

I'm very open to both black and a linter.

Now is a fairly good time since v3.2.0 is essentially minted and most likely the next release will be v4 which will drop support for Python2 and start to add typing annotations. In another project I was also supporting Python2 and wanted type annotations and to use black but they were a bit incompatible a year ago.

Due to the slow nature of reviewing and adding new interfaces I think there will never be a conflict free time to do it.

[karlding]

Sounds good!

I believe a patch went into black at the end of last year that took a stab at supporting that. Perhaps that supports enough of the use case that you were hoping to cover?

[felixdivo]

I was about to propose this a few weeks back as well! I would love it. 👍

[felixdivo]

@karlding added a formatter in #602

[felixdivo]

Related (about Pylint): #613