Open Stack

> On Mar 25, 2015, at 4:22 PM, Monty Taylor <mordred at inaugust.com> wrote:
> 
> On 03/25/2015 05:50 PM, Maru Newby wrote:
>> I am excited by the release of YAPF [1], a gofmt-like too for python.
>> I think it has the potential to simplify style enforcement, and as
>> much as I appreciate our current hacking checks, I’d be much happier
>> not requiring developers to manually conform to them.  Maybe we can
>> consider automation in a manner similar to that employed by the go
>> codereview tool [2]?
> 
> I played with it for a few minutes and although it's configurable, it's
> still pretty limited in terms of expressiveness.
> 
> That said - although I do appreciate the theory of auto-formatting
> (seriously, one less thing, right?) I think it would be problematic for
> us. You can't ship git hooks in a git repo, so we can't help our users
> know to run it before pushing. In a world where getting set up in
> openstack is already non-trivial, I think requiring 2500 developers to
> add a new git hook to every repo that they do something with would be a
> bit of a disaster. When you combine that with the people who won't know,
> will make a patch, send it up, and have it rejected --- oy. Chaos.
> 
> git review is used by a ton of people who write in non-python. I think
> adding openstack-specific style enforcement to it would make it way less
> generally useful.
> 
> In general, if you find it interesting, there's certainly nothing wrong
> with tracking it and poking at it from time to time. But I honestly
> think that the logistical issue is pretty large, and one that the payoff
> from solving would not be worth the effort.

I agree with points raised by you and jeblair regarding the
potential for problems in applying auto-formatting without
developer intervention.  I apologize if my use of the word
'automation' muddied the waters, as the go codereview tool's
support of the 'gofmt' command is limited to explicit invocation
rather than being triggered in a hook.  It doesn't appear
acceptable for git-review to be granted similar capability, but
really that is a nicety.  Individual projects can as easily
provide their own style definitions, include YAPF as a test
dependency, and document how to invoke it.

I think there is value in extending our current solution of
automated style enforcement to provide a component that can be
manually invoked to auto-format to the enforced style.  I don't
see virtue in applying manual effort to maintaining code style.
YAPF may not be ready for our use just yet, but I think it's
worth pursuing. 


Maru