Open Stack

On Thu, 2019-04-18 at 11:56 +0200, Dmitry Tantsur wrote:
> On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
> > Black is a python code formatter, something similar to the older
> > yapf.
> > 
> > I do like to avoid discussions about formatting in code reviews and
> > prefer to let the linter take care of what could count as
> > appointed.
> 
> That's what pep8 jobs are for. They cannot be replaced with a pre-
> commit hooks, because people who are mostly likely to screw up
> formatting are also most likely to not have it installed.
> 
> > My experience with yapf was far from idea as they decided to change
> > formatting in a major way in their last *minor* version update,
> > breaking havoc.
> > 
> > There is one reason why I did not even try black: it does require
> > python3.6 !!!
> > 
> > While I do have a huge range of python version installed on my own
> > dev machines, I cannot say the same about the average
> > developer/contributor.
> > 
> > Considering that on CentOS-7 you can only get python3.5... this
> > rest my case.
> 
> You're welcome: 
> https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)

You've also got tox and virtualenvs in general, but I don't think this
is a serious issue tbh...

> > I do not want to limit the number of platform for contributors on
> > any project, especially when we talk about one of the most
> > basic/early check a developer would have to run on any change they
> > make.
> > 
> > That is why -1 on black, and I guess it will be like this until we
> > have CentOS 8 released. On the other hand, about yapf use I have
> > mixed feelings.
> > 
> > I would rather prefer to see better adoption/coverage of: flake8,
> > ansible-lint and yamllint -- preferably orchestrated via pre-commit 
> > as it lowers the execution time and disk footprint (sharing/caching
> > identical linters between repositories) -- opposed to tox which
> > does not shared anything between repositories. Tripleo-quickstart
> > and tripleo-ci repositories are already using it and I did not hear
> > many complaints, other than having to explain that pre-commit is
> > does not require the use of a git hook.
> 
> I think we already use flake8 openstack-wide, what will Black bring
> us in addition to that?

I've seen this used with packages such as tox and warehouse (the new
code base for pypi.org). black is intended to be an opinionated code
formatter and exposes no knobs to the user, meaning it's very much
"their way or the highway". This makes it different from something like
yapf, which exposes all these knobs and therefore allows for arguments
about e.g. whether one should use single or double quotes. No
configuration knobs means no ability to discuss these preferences,
which for something as subjective as code formatting seems to be a good
thing to me.

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.

Stephen

PS: As an aside, I would like to see something like black provided as
part of the Python standard library to settle formatting issues for
once and for all and help ensure that a minimum standard is set for
most code you'll find (though code quality covers far more than mere
formatting). To the best of my knowledge, the gofmt tool in go(lang)
fills this role but I really can't see that happening within Python any
time soon.

> Dmitry
> 
> > 
> > Shortly, +2 on more pre-commit use, the tool not the git hook.
> > 
> > 
> > PS. Please do not bring the SCL into the thread, they do not
> > provide a single command enablement of additional python
> > interpreters (not in PATH).
> > 
> > > On 18 Apr 2019, at 09:57, Dmitry Tantsur <dtantsur at redhat.com>
> > > wrote:
> > > 
> > > Hi,
> > > 
> > > On 4/18/19 10:51 AM, Natal Ngétal wrote:
> > > > Hi everyone,
> > > > Black is project to format Python code. It's more and more used
> > > > by the python community. That can save time and harmonize the
> > > > code. For example, simple quote versus double quote, that was
> > > > not checked by pep8.i It's just an example of what make  black
> > > > With a pre-hook commit hook this will be also avoid to lose
> > > > time with pep8 errors.
> > > 
> > > I'm not sure what exactly Black does, but the last thing I want
> > > to see is patches changing between single and double quotes. If
> > > it's not the case or it can be turned off, I'm all for
> > > experimenting.
> > > 
> > > > Two links to see more:
> > > > https://github.com/ambv/black
> > > > https://www.mattlayman.com/blog/2018/python-code-black/
> > > > I think it can be very interesting to start to use Black on
> > > > OpenStack. What do you thinks about that? For example, we can
> > > > introduce it on some projects, I would volunteer to try on
> > > > TripleO.
> > > 
> > > Given it's a pre-commit hook, isn't it supposed to be done on
> > > developer's machines? If so, how do you see applying Black to the
> > > whole OpenStack?
> > > 
> > > Dmitry
> > > 
> > > > My best regards