The python black project.
On 2019-04-23 20:22:04 +0100 (+0100), Sean Mooney wrote:
> On Tue, 2019-04-23 at 19:06 +0000, Fox, Kevin M wrote:
> > On Tue, 2019-04-23 at 15:39 +0000, Jeremy Stanley wrote:
> > > 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.
> > 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
That's basically exactly what I said up-thread... there's nothing
stopping you from setting your environment up to run your diff
through autopep8 before committing, for example via a local Git
hook. If you want others to do the same, you need to solve the hook
distribution and installation problem. We already refuse to merge
changes which fail our pep8 CI jobs, so that's effectively the same
as running autopep8 in a job and returning a diff in the logs (but
harder to do things like start taking advantage of Zuul's
recently-added ability to leave inline review comments, since you'd
no longer have the line-oriented reports flake8 gives you, though I
guess the same job could *also* run autopep8, it's not like it would
add much to the job duration).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 963 bytes
Desc: not available