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. im not sure about the later point. i mess up pep8 with parctially every patch and i have worked on openstack/python for almost 6 years at this point but i agree it cant replace the pep8 job but we shoudl also have a black job.
also we could easily provide a tox -e black to do the formatting.
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 can get 3.6 on centos. that is what my dev vms ues by default. python3.6 is shiped in the epel repos and centos defaults to python 3.4 py3.5 was the version i tought you could not easily install on centos7
You're welcome: https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)
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 have not looked at black but if its anything like clang-format or go's gofmt tool there is a lot to be gained by haveing a tool format all code in a repo to follow a project/langage specific coding style with 0 human interaction required. i we were to apply this to openstack we woudl need a singel mechanical commit that used black to reformat all code in a repo which also intoduces a black gate jobs. the black gate job going forward would reject any patch that would require black to modify it. e.g. the job woudl take the change run black and check git diff to see if anything changed. if it did fail if it didn't pass.
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@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