[openstack-dev] pep8 pinning in requirements

James E. Blair jeblair at openstack.org
Wed Mar 20 16:55:59 UTC 2013


Thierry Carrez <thierry at openstack.org> writes:

> Sean Dague wrote:
>> I noticed yesterday with the cinder review that pep8 was listed as >=
>> 1.3, and not pinned. I think this is a really bad idea.
>> 
>> After a large amount of pep8 churn at the end of Folsom, we agreed to
>> pin pep8 for Grizzly, and it was good. It prevented huge numbers of
>> churn patches because a new pep8 minor release came out and now we
>> needed an extra space somewhere to pass the scanner.
>
> I've been discussing this with someone recently (Jim, I think). PEP8 is
> a great set of rules to enforce common style and I'm very happy that we
> use it. However we don't really need that much pep8 *tool* to evolve
> over time. Adapting corner-case spacing over a 1MLOC codebase brings us
> no real value...
>
> The issue is that the pep8 tool liberally accepts bugfixes to existing
> tests, and new interpretations of the established rules, both in the
> same point releases.
> ...

Indeed, pep8-the-tool has recently started taking a very liberal
interpretation of pep8-the-spec, so much that in the default
configuration it is enforcing things that are not in the spec at all.
As a set of suggestions, that's fine.  But I agree that we should not
subject our 1MLOC code base to what are essentially at this point the
whims of a single developer, particularly since we use this in gating
tests.

Monty has been looking into a new tools called 'flake8' that can run
pyflakes, pep8, and other hacking.py style tests in a modular manner.
I'd like to see if we can use that to sensibly set a global
configuration of fairly conservative pep8 tests.

Alternatively, I'm also in favor of continuing to pin to a more
conservative version of the pep8 tool, or to even fork it and maintain
something that is more true to the spec -- after all, I believe the goal
is that it _should not_ change often.

The value in standards is in interoperability, and pep8 was wisely put
forward as a way to not only make python code formatting standardized so
that humans can easily read each others code, but so that our editors
and tools can all be programmed to read and generate similar code.  The
more we stick to the standard, the less wasted work for everyone.

-Jim



More information about the OpenStack-dev mailing list