Open Stack

---- On Tue, 12 May 2020 13:07:43 -0500 Brian Haley <haleyb.dev at gmail.com> wrote ----
 > On 5/12/20 1:23 PM, Ghanshyam Mann wrote:
 > <snip>
 > 
 > >   > > This is also failing on some stable branches that had not moved to
 > >   > > hacking 3.0 yet. In this case, it may be better to add a flake8 cap to
 > >   > > the repo's test-requirements.txt file rather than backporting a major
 > >   > > bump in hacking and dealing with the need to make a lot of code changes.
 > >   > >
 > >   > > Here is an example of that approach:
 > >   > >
 > >   > > https://review.opendev.org/#/c/727265/
 > >   >
 > >   > I found in the neutron stable/ussuri repo that capping flake8<3.8.0
 > >   > didn't work, but capping pycodestyle did.  So that's another option.
 > >   >
 > >   > -pycodestyle>=2.0.0 # MIT
 > >   > +pycodestyle>=2.0.0,<2.6.0 # MIT
 > >   >
 > >   > https://review.opendev.org/#/c/727274/

Adding what we discussed on IRC about the workable solution. 

flake8 2.6.2 which is pulled by older hacking in stable/train and less does not have
cap for pycodestyle so if test-requirement.txt has "pycodestyle>***" then you need
to cap it explicitly with what Brian proposed in https://review.opendev.org/#/c/727274/

otherwise flake8 2.6.2 will pull the new  pycodestyle and break.

-gmann

 > > 
 > > I will say remove rhe pycodestyle from neutron test-reqruiement and let hacking
 > > via flake8 cap handle the compatible pycodestyle. Otherwise we end up maintaining and
 > > fixing it project side for future.
 > 
 > So the problem in this case was having both of these in 
 > test-requirements.txt:
 > 
 > flake8>=3.6.0,<3.8.0 # MIT
 > pycodestyle>=2.0.0 # MIT
 > 
 > Test versions were:
 > 
 > flake8==3.7.9
 > pycodestyle==2.6.0
 > 
 > Removing the pycodestyle line altogether worked however, it pulled 
 > pycodestye 3.5.0 then.
 > 
 > -Brian
 > 
 >