I'd recommend that you consider an auto-formatter over a style-linter - such as yapf or autopep8 - and have the auto-formatting applied as a pre-commit step (and validated in tests, or on CI) Autoformatters reduce the burden of conformance on developers, avoid mixed style-and-feature-change patches, and moves the focus of code-review towards the intended changes and away from nit-picking. All together, they remove complexity for those new to a project. One discussion on the subject -- there are many others, especially from people who've programmed some Go, where auto-formatting is mandatory. https://groups.google.com/forum/#!topic/python-ideas/xute5NmXRps On 15 November 2016 at 23:12, Liam Stewart <liam.stewart@gmail.com> wrote:

We have multiple python projects over multiple (private) repos in github and I would like all of them to share a standard, organization-wide style (eg. line length, any explicit select/ignore settings, etc.). Each individual project could have a configuration that contained project-specific settings. This would normally be additional ignore settings (eg. to gradually transition a project to our style rule by rule). Ideally, a developer should be able to run a single command to do style checks.

I'm looking for guidance about how to go about doing this with flake8. What I was thinking was that we'd have a private python package that brings in flake8 plus any plugin packages and custom extensions (similar to hacking); it would also bring in the global configuration file. In this way, projects could simply add, say, <org>-flake8 to their requirements.txt file. I'm pretty sure that we'd need a wrapper script to handle the global configuration. The question is more about how to specify the global config correctly.

flake8's doesn't seem to have the notion of a global base configuration; the closest thing is the user configuration, but that is layered on top of whatever project configuration there is. The "--config" argument isn't useful as that forces a single configuration file. "--append-config" is a possibility. A wrapper that runs flake8 with --append-config to layer first global + local could work but local settings would have to be in a fixed file. We'd layer local-global-local. That's sort of ok, but would lead to surprising results if a dev put settings in say "setup.cfg" and the wrapper always tried ".flake8" (though we could minimize such surprises by specifying all known project file names..).

Is there another way to go about this that I haven't considered? Would it be reasonable to add a "--prepend-config" argument? In which case the layering order would be prepend, local files, append, user. (Happy to submit a PR or whatever the gitlab equivalent is.)

Thanks,

liam

-- Liam Stewart :: liam.stewart@gmail.com

_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality