The python black project.
Dmitry Tantsur
dtantsur at redhat.com
Thu Apr 18 10:53:21 UTC 2019
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).
More information about the openstack-discuss
mailing list