[openstack-dev] pep8 pinning in requirements

Chuck Short chuck.short at canonical.com
Wed Mar 20 15:25:44 UTC 2013


Hi,

On 13-03-20 11:06 AM, Sean Dague wrote:
> On 03/20/2013 10:52 AM, Thierry Carrez wrote:
>> 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. Ideally it would separate the set of rules being
>> used from the version being used, something like
>>
>> pep8 --party-like-it-was=2013-01-01
>>
>> that would let you use latest pep8 version with the rules as they stood
>> at the beginning of this year.
>>
>> Alternatively, we could freeze our pep8 version... but the distros tend
>> to ship with a relatively-current version.
>
> Also, we monkey patch it in some "interesting" ways to get our own 
> hacking.py working (which is hugely helpful in saving human brain 
> cells on enforcing HACKING). So it's important that we don't let it 
> change out from under us in a way that breaks hacking.py.
>
> pep8 is in test-requires, so it doesn't really matter what the distros 
> ship. When you run our tests you'll get our version.

Actually it does matter which version pep8 that the distros ship. Ubuntu 
for example runs the full tests on each commit in our CI lab so if our 
versions of pep8 are not in sync then we will have to carry an out of 
tree patch or Openstack will get a wrong bug report.

> Moving it forward to a new pinned version at the beginning of every 
> cycle seems a happy compromise between being current on pep8, and not 
> churning wildly. Right now lots of projects ignore huge swaths of pep8 
> rules to deal with the interpretation changes (this was a local fix to 
> dealing with pep8 changing too often before it was pinned in grizzly).
>
>     -Sean
>




More information about the OpenStack-dev mailing list