On Thu, 2019-04-18 at 12:53 +0200, Dmitry Tantsur wrote:
On 4/18/19 12:46 PM, Chris Dent wrote:
On Thu, 18 Apr 2019, Stephen Finucane wrote:
Now, as to whether it's practical, you have to realize that for it to be of any use, black has to be run initially over your entire codebase and then rerun on each commit. The latter isn't an issue (we already run flake8 for this purpose) but I genuinely cannot see something like nova rewrapping every line of code (all 552,347 of them, if my quick check is correct), essentially breaking the ability to cleanly backport patches and get meaningful 'git blame' output simply to avoid the occasional debate about code formatting. I think adopting black for a _new_ project (or even a very small one) could be a great idea, but for something as large and cumbersome as nova (or neutron, glance, cinder, some of the oslo libraries, etc.), maaaaaybe not.
Exactly this. Introducing black to an existing project with a long history is pretty much a non-starter.
The fact that it provides no knobs is, as you say, a feature (everyone must must bow to the same evil dictator).
... except when somebody blocks the adoption completely because of a dislike for some aspect :) This is where a tool officially blessed by the Python core team would come handier (like 'go fmt', 'cargo fmt', etc). yes but it does not need to be the python core team that blesses it. for yapf which is based on clang-format you can provide project specific styles.
so we could have an openstack style that we applied however to do that i think this would need the help of the TC and consultation with all projects to a.) agree on a tool b.) agree on a style config and c.) agree on an implementation path. indivigual projects, espically small/new ones could standardise on a tool/style themselves but in the absence of a blessed formater form the Python core team if we wanted to adopt this in openstack as a whole it would have to become part of the PTI which would require TC involvement and comunity buy in.