Open Stack

On Tue, 2019-04-23 at 18:39 +0000, Jeremy Stanley wrote:
> 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.
i honestly have been a little reluctanet to do that in the past jsut because
it might cause unrelated changes and peopel will nit pick them as such.
>  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).
well looking at autopep8 again its much less invasive then i had assumed it would
be so i might start using it locally personally.
> 
> 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.
honestly i was thinking if we went with autopep8 we just add it to the pep8 tox env.
so you run pep8 locally/in the gate and it fixes everythign it can and if there are any failure
you can jsut fix them youself.

the fact that auto pep8 seams to be really concervitve and only fix pep8 issues which flake8 would
not allow anyway is a saving grace as it mean there will be very litte code churn.

also autopep8 is the default formater for python in vscode and other ids support it too so
for those that use them its pretty trivial to use by pressing ctrl+shift+i to format the current file.
that said it dose not help me when im using nano/emacs but i run tox -e pep8 anyway before i push.
if that auto fixed pep8 issue too when it could that would be nice.

one thing that i think is important however is that the authorship of the change not be effected so
in the gate if autopep8 would casuse a code chagne i would want the job to fail.

maybe haveign the two be seperate woudl actully be better e.g. have an autopep8 tox env jsut for running it.
im honestly getting burt out by this topic but i thin this could be a nice middle ground.
that or stay as we are but my inital exciment over maybe useing black has been extinguished by
actully using it and this thread.