<div dir="ltr">Hi all,<div><br></div><div>In general, I would like to have black formatter for the OpenStack code.</div><div><br></div><div>I agree with the points mentioned above about git blame. Also, I really</div><div>don't want to have dozens of patches just to address few more black rules</div><div>in the existing code base.</div><br class="gmail-Apple-interchange-newline"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,<br>Ivan Kolodyazhny,<br><a href="http://blog.e0ne.info/" target="_blank">http://blog.e0ne.info/</a></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 18, 2019 at 2:18 PM Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 2019-04-18 at 13:02 +0200, Slawomir Kaplonski wrote:<br>
> Hi,<br>
> <br>
> > Wiadomość napisana przez Stephen Finucane <<a href="mailto:sfinucan@redhat.com" target="_blank">sfinucan@redhat.com</a>> w dniu 18.04.2019, o godz. 12:33:<br>
> > <br>
> > On Thu, 2019-04-18 at 11:56 +0200, Dmitry Tantsur wrote:<br>
> > > On 4/18/19 11:52 AM, Sorin Sbarnea wrote:<br>
> > > > Black is a python code formatter, something similar to the older<br>
> > > > yapf.<br>
> > > > <br>
> > > > I do like to avoid discussions about formatting in code reviews and<br>
> > > > prefer to let the linter take care of what could count as<br>
> > > > appointed.<br>
> > > <br>
> > > That's what pep8 jobs are for. They cannot be replaced with a pre-<br>
> > > commit hooks, because people who are mostly likely to screw up<br>
> > > formatting are also most likely to not have it installed.<br>
> > > <br>
> > > > My experience with yapf was far from idea as they decided to change<br>
> > > > formatting in a major way in their last *minor* version update,<br>
> > > > breaking havoc.<br>
> > > > <br>
> > > > There is one reason why I did not even try black: it does require<br>
> > > > python3.6 !!!<br>
> > > > <br>
> > > > While I do have a huge range of python version installed on my own<br>
> > > > dev machines, I cannot say the same about the average<br>
> > > > developer/contributor.<br>
> > > > <br>
> > > > Considering that on CentOS-7 you can only get python3.5... this<br>
> > > > rest my case.<br>
> > > <br>
> > > You're welcome: <br>
> > > <a href="https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72" rel="noreferrer" target="_blank">https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72</a> :)<br>
> > <br>
> > You've also got tox and virtualenvs in general, but I don't think this<br>
> > is a serious issue tbh...<br>
> > <br>
> > > > I do not want to limit the number of platform for contributors on<br>
> > > > any project, especially when we talk about one of the most<br>
> > > > basic/early check a developer would have to run on any change they<br>
> > > > make.<br>
> > > > <br>
> > > > That is why -1 on black, and I guess it will be like this until we<br>
> > > > have CentOS 8 released. On the other hand, about yapf use I have<br>
> > > > mixed feelings.<br>
> > > > <br>
> > > > I would rather prefer to see better adoption/coverage of: flake8,<br>
> > > > ansible-lint and yamllint -- preferably orchestrated via pre-commit <br>
> > > > as it lowers the execution time and disk footprint (sharing/caching<br>
> > > > identical linters between repositories) -- opposed to tox which<br>
> > > > does not shared anything between repositories. Tripleo-quickstart<br>
> > > > and tripleo-ci repositories are already using it and I did not hear<br>
> > > > many complaints, other than having to explain that pre-commit is<br>
> > > > does not require the use of a git hook.<br>
> > > <br>
> > > I think we already use flake8 openstack-wide, what will Black bring<br>
> > > us in addition to that?<br>
> > <br>
> > I've seen this used with packages such as tox and warehouse (the new<br>
> > code base for <a href="http://pypi.org" rel="noreferrer" target="_blank">pypi.org</a>). black is intended to be an opinionated code<br>
> > formatter and exposes no knobs to the user, meaning it's very much<br>
> > "their way or the highway". This makes it different from something like<br>
> > yapf, which exposes all these knobs and therefore allows for arguments<br>
> > about e.g. whether one should use single or double quotes. No<br>
> > configuration knobs means no ability to discuss these preferences,<br>
> > which for something as subjective as code formatting seems to be a good<br>
> > thing to me.<br>
> > <br>
> > Now, as to whether it's practical, you have to realize that for it to<br>
> > be of any use, black has to be run initially over your entire codebase<br>
> > and then rerun on each commit. The latter isn't an issue (we already<br>
> > run flake8 for this purpose) but I genuinely cannot see something like<br>
> > nova rewrapping every line of code (all 552,347 of them, if my quick<br>
> > check is correct), essentially breaking the ability to cleanly backport<br>
> > patches and get meaningful 'git blame' output simply to avoid the<br>
> > occasional debate about code formatting. I think adopting black for a<br>
> > _new_ project (or even a very small one) could be a great idea, but for<br>
> > something as large and cumbersome as nova (or neutron, glance, cinder,<br>
> > some of the oslo libraries, etc.), maaaaaybe not.<br>
> <br>
> +100 to this. Resolving manually many conflicts between master and stable branches just because e.g. quoting was<br>
> changed doesn’t seems like good thing :)<br>
you realise if we also applied this to the stable branches too we would never need to resolve<br>
a merge conflict due to formating again or correct any pep8/style issues on backports.<br>
but yes its a valid concern.<br>
<br>
i guess the general feedback so far has been unless there is a way to do it incrementally this is a non starter.<br>
that is sad but if that is how people feel ill let this to the original poster to fight.<br>
> <br>
> > <br>
> > Stephen<br>
> > <br>
> > PS: As an aside, I would like to see something like black provided as<br>
> > part of the Python standard library to settle formatting issues for<br>
> > once and for all and help ensure that a minimum standard is set for<br>
> > most code you'll find (though code quality covers far more than mere<br>
> > formatting). To the best of my knowledge, the gofmt tool in go(lang)<br>
> > fills this role but I really can't see that happening within Python any<br>
> > time soon.<br>
> > <br>
> > > Dmitry<br>
> > > <br>
> > > > <br>
> > > > Shortly, +2 on more pre-commit use, the tool not the git hook.<br>
> > > > <br>
> > > > <br>
> > > > PS. Please do not bring the SCL into the thread, they do not<br>
> > > > provide a single command enablement of additional python<br>
> > > > interpreters (not in PATH).<br>
> > > > <br>
> > > > > On 18 Apr 2019, at 09:57, Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>><br>
> > > > > wrote:<br>
> > > > > <br>
> > > > > Hi,<br>
> > > > > <br>
> > > > > On 4/18/19 10:51 AM, Natal Ngétal wrote:<br>
> > > > > > Hi everyone,<br>
> > > > > > Black is project to format Python code. It's more and more used<br>
> > > > > > by the python community. That can save time and harmonize the<br>
> > > > > > code. For example, simple quote versus double quote, that was<br>
> > > > > > not checked by pep8.i It's just an example of what make  black<br>
> > > > > > With a pre-hook commit hook this will be also avoid to lose<br>
> > > > > > time with pep8 errors.<br>
> > > > > <br>
> > > > > I'm not sure what exactly Black does, but the last thing I want<br>
> > > > > to see is patches changing between single and double quotes. If<br>
> > > > > it's not the case or it can be turned off, I'm all for<br>
> > > > > experimenting.<br>
> > > > > <br>
> > > > > > Two links to see more:<br>
> > > > > > <a href="https://github.com/ambv/black" rel="noreferrer" target="_blank">https://github.com/ambv/black</a><br>
> > > > > > <a href="https://www.mattlayman.com/blog/2018/python-code-black/" rel="noreferrer" target="_blank">https://www.mattlayman.com/blog/2018/python-code-black/</a><br>
> > > > > > I think it can be very interesting to start to use Black on<br>
> > > > > > OpenStack. What do you thinks about that? For example, we can<br>
> > > > > > introduce it on some projects, I would volunteer to try on<br>
> > > > > > TripleO.<br>
> > > > > <br>
> > > > > Given it's a pre-commit hook, isn't it supposed to be done on<br>
> > > > > developer's machines? If so, how do you see applying Black to the<br>
> > > > > whole OpenStack?<br>
> > > > > <br>
> > > > > Dmitry<br>
> > > > > <br>
> > > > > > My best regards<br>
> <br>
> — <br>
> Slawek Kaplonski<br>
> Senior software engineer<br>
> Red Hat<br>
> <br>
> <br>
<br>
<br>
</blockquote></div>