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.stew...@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.stew...@gmail.com > > _______________________________________________ > code-quality mailing list > code-quality@python.org > https://mail.python.org/mailman/listinfo/code-quality > >
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
