Open Stack

On Tue, 2019-04-23 at 19:06 +0000, Fox, Kevin M wrote:
> I've wondered for a while if you could automate the automation. So, like, run the autoformatter and feed back the
> generated patch back to the developer in a way they can easily accept it. Like, making a pr against their pr with the
> formatting fixes, so that they can easily merge it in.
well you can with a pre-commit hook + a job chagne to enforce it.
so pre-commit hook runs an autopep8 tox env.
if the tox run modifies any files fail the commit.
in the gate we also assert the same thing in the pep8 job.
and retrun the diff in the logs somewhere

anyway i know not everyone would be on board with that but its what i would proably do if i was starting proejct from
scratch.

> 
> Thanks,
> Kevin
> ________________________________________
> From: Jeremy Stanley [fungi at yuggoth.org]
> Sent: Tuesday, April 23, 2019 11:39 AM
> To: openstack-discuss at lists.openstack.org
> Subject: Re: The python black project.
> 
> On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote:
> [...]
> > ya i think i could get more behind autopep8 or yapf. running
> > autopep8  on nova https://review.opendev.org/#/c/655171/ has very
> > little change
> > 
> > litrally adding 1 empty new line to  to 102 files that with almost
> > 0 other code curn. using autopep8 however would fix any actul pep8
> > issue in new patches automatically without the downsides of black.
> 
> [...]
> 
> I'm more concerned with the implementation logistics, honestly. How
> do you propose going about this? If you want to use a Git commit or
> pre-commit hook then you can do it already--go for it. If you want
> everyone proposing changes to the same repository to use the same
> commit hook, that becomes a distribution/enforcement challenge to
> solve. If you want it somehow enforced on the receiving end of the
> push, say with a receive hook, that's brittle and will have side
> effects such as invalidating signed commits (which we're able to
> support at the moment).
> 
> Basically the only friendly and reliable way to enforce this
> centrally is to have the desired style conventions validated upon
> receipt by the code review system and the results reported back to
> the committer. This is exactly what we already do today. There are
> of course also ways to reject the change with a push error so that
> the committer has to amend and push again, but that's not easy to
> manage across different projects and also doesn't solve your desire
> to "not need to think about code style" (paraphrased).
> 
> There is also the possibility that you simply run a periodic
> autopep8 job against the codebase and have that job propose a commit
> to the repository to apply code style changes if there are any, but
> that's a bit of a messy hack as well.
> --
> Jeremy Stanley
>