[openstack-dev] pep8 pinning in requirements
Sean Dague
sean at dague.net
Wed Mar 20 17:27:57 UTC 2013
On 03/20/2013 12:46 PM, Thomas Goirand wrote:
> On 03/20/2013 07:53 PM, 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.
>
> I do think it always should be this way, and not only with pep8, but
> with as much python tools as possible, including all the test suite.
>
>> 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.
>
> Well, from a distribution standpoint, imposing such a restrictive
> build-dependency is just crazy. In Debian, there's either pep8 1.2 (in
> Wheezy which is frozen) or 1.4.4 (in SID). It's like that, and it wont
> change soon, unless there is a new upstream release. There will never be
> a 1.3.3. This kind of situation is likely to happen in other
> distributions than Debian.
>
>> I realize that we're trying to uncap as many deps as possible, but I
>> think doing that for pep8 isn't the right call, because of the amount of
>> code churn it causes.
>
> Then pep8 is either a bad software, or it isn't updated to Openstack.
> IMO, it should always be backward compatible, and be able to validate
> the same old code it did validate few versions ago.
>
>> I think at the beginning of every release cycle we should bump pep8 to
>> the latest release version
>
> PLEASE DON'T !!!
>
> Openstack already made my Debian package maintainer life miserable,
> because there was only version 1.2 in SID. I don't want to have to spend
> my life convincing the maintainer of pep8 to upload a new release.
>
> Now, imagine if all upstream authors were thinking like Openstack. The
> only way to be able to use pep8 would be to have as many version of pep8
> in Debian as there is upstream project using it.
So, I'm confused....
As a packager you are re-running the development internal style checkers
on released code? and if so, why?
I can understand rerunning unit tests to make sure that you didn't break
function in patching openstack, but I actually don't understand at all
why you'd run style enforcement on code during packaging.
-Sean
--
Sean Dague
http://dague.net
More information about the OpenStack-dev
mailing list