[all] pep8 job failing due to flake8 3.8.0
Hello Everyone. You might have noticed that few or most of the projects pep8 job started failing. That is because flake8 new version 3.8.0 added the new pycodestyle with new rules. Hacking capped it with 4.0.0 version not with the minor version for 3.*. The new hacking version 3.0.1 is released which cap the flake8<3.8.0. Thanks to dtantsur and stephenfin for tacking care of it. To fix your pep8 job you can, - Either fix the pep8 error in code if easy and fast to fix. - Or bump the hacking minimum version to 3.0.1. I have proposed it for a few projects failing pep8. - https://review.opendev.org/#/q/topic:hacking-fix+(status:open+OR+status:merg...) If pep8 job is passing then you do not need to do anything. The existing hacking version cap will work fine. -gmann
On 5/12/20 11:14 AM, Ghanshyam Mann wrote:
Hello Everyone.
You might have noticed that few or most of the projects pep8 job started failing.
That is because flake8 new version 3.8.0 added the new pycodestyle with new rules. Hacking capped it with 4.0.0 version not with the minor version for 3.*.
The new hacking version 3.0.1 is released which cap the flake8<3.8.0. Thanks to dtantsur and stephenfin for tacking care of it.
To fix your pep8 job you can,
- Either fix the pep8 error in code if easy and fast to fix.
- Or bump the hacking minimum version to 3.0.1. I have proposed it for a few projects failing pep8. - https://review.opendev.org/#/q/topic:hacking-fix+(status:open+OR+status:merg...)
If pep8 job is passing then you do not need to do anything. The existing hacking version cap will work fine.
-gmann
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/
On 5/12/20 12:25 PM, Sean McGinnis wrote:
On 5/12/20 11:14 AM, Ghanshyam Mann wrote:
Hello Everyone.
You might have noticed that few or most of the projects pep8 job started failing.
That is because flake8 new version 3.8.0 added the new pycodestyle with new rules. Hacking capped it with 4.0.0 version not with the minor version for 3.*.
The new hacking version 3.0.1 is released which cap the flake8<3.8.0. Thanks to dtantsur and stephenfin for tacking care of it.
To fix your pep8 job you can,
- Either fix the pep8 error in code if easy and fast to fix.
- Or bump the hacking minimum version to 3.0.1. I have proposed it for a few projects failing pep8. - https://review.opendev.org/#/q/topic:hacking-fix+(status:open+OR+status:merg...)
If pep8 job is passing then you do not need to do anything. The existing hacking version cap will work fine.
-gmann
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:
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/ -Brian
On Tue, 2020-05-12 at 13:00 -0400, Brian Haley wrote:
On 5/12/20 12:25 PM, Sean McGinnis wrote:
On 5/12/20 11:14 AM, Ghanshyam Mann wrote:
Hello Everyone.
You might have noticed that few or most of the projects pep8 job started failing.
That is because flake8 new version 3.8.0 added the new pycodestyle with new rules. Hacking capped it with 4.0.0 version not with the minor version for 3.*.
The new hacking version 3.0.1 is released which cap the flake8<3.8.0. Thanks to dtantsur and stephenfin for tacking care of it.
To fix your pep8 job you can,
- Either fix the pep8 error in code if easy and fast to fix.
- Or bump the hacking minimum version to 3.0.1. I have proposed it for a few projects failing pep8. - https://review.opendev.org/#/q/topic:hacking-fix+(status:open+OR+status:merg...)
If pep8 job is passing then you do not need to do anything. The existing hacking version cap will work fine.
-gmann
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:
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 ya i created a test env on ubuntu 20.04 with python 3.8 and i had the issue and then if i downgraded flake8 to even 3.5.0
if i do /opt/repos/nova$ .tox/venv/bin/pip install -U pycodestyle\<2.6 flake8\<3.8 and then run pep8 in nova it still fails not resovle the issue ubuntu@devstack-ubuntu-latest:/opt/repos/nova$ .tox/venv/bin/pip freeze | grep -E "flake8|pycodestyle" flake8==3.7.9 pycodestyle==2.5.0 and i went older too ubuntu@devstack-ubuntu-latest:/opt/repos/nova$ .tox/venv/bin/pip freeze | grep -E "flake8|pycodestyle" flake8==3.6.0 pycodestyle==2.4.0 on ubuntu 20.04 under python 3.8 all of the above fail with the same errors for nova. so there is something more going on then just flake8 and pycodestyle i think.
https://review.opendev.org/#/c/727274/
-Brian
---- On Tue, 12 May 2020 12:20:19 -0500 Sean Mooney <smooney@redhat.com> wrote ----
On Tue, 2020-05-12 at 13:00 -0400, Brian Haley wrote:
On 5/12/20 12:25 PM, Sean McGinnis wrote:
On 5/12/20 11:14 AM, Ghanshyam Mann wrote:
Hello Everyone.
You might have noticed that few or most of the projects pep8 job started failing.
That is because flake8 new version 3.8.0 added the new pycodestyle with new rules. Hacking capped it with 4.0.0 version not with the minor version for 3.*.
The new hacking version 3.0.1 is released which cap the flake8<3.8.0. Thanks to dtantsur and stephenfin for tacking care of it.
To fix your pep8 job you can,
- Either fix the pep8 error in code if easy and fast to fix.
- Or bump the hacking minimum version to 3.0.1. I have proposed it for a few projects failing pep8. - https://review.opendev.org/#/q/topic:hacking-fix+(status:open+OR+status:merg...)
If pep8 job is passing then you do not need to do anything. The existing hacking version cap will work fine.
-gmann
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:
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 ya i created a test env on ubuntu 20.04 with python 3.8 and i had the issue and then if i downgraded flake8 to even 3.5.0
if i do /opt/repos/nova$ .tox/venv/bin/pip install -U pycodestyle\<2.6 flake8\<3.8 and then run pep8 in nova it still fails not resovle the issue
ubuntu@devstack-ubuntu-latest:/opt/repos/nova$ .tox/venv/bin/pip freeze | grep -E "flake8|pycodestyle" flake8==3.7.9 pycodestyle==2.5.0
and i went older too ubuntu@devstack-ubuntu-latest:/opt/repos/nova$ .tox/venv/bin/pip freeze | grep -E "flake8|pycodestyle" flake8==3.6.0 pycodestyle==2.4.0
on ubuntu 20.04 under python 3.8 all of the above fail with the same errors for nova.
so there is something more going on then just flake8 and pycodestyle i think.
This might be something else. hacking 3.0.1 will pull the flake8 2.7.9 and pycodestyle 2.5.0 [1] that is what I see in python-novaclient changes - https://zuul.opendev.org/t/openstack/build/c9c3ed3010d64af685ce8aecc699864c/... [1] - https://gitlab.com/pycqa/flake8/-/blob/ee2920d775df18481d638c2da084d229d56f9...
https://review.opendev.org/#/c/727274/
-Brian
---- On Tue, 12 May 2020 12:00:11 -0500 Brian Haley <haleyb.dev@gmail.com> wrote ----
On 5/12/20 12:25 PM, Sean McGinnis wrote:
On 5/12/20 11:14 AM, Ghanshyam Mann wrote:
Hello Everyone.
You might have noticed that few or most of the projects pep8 job started failing.
That is because flake8 new version 3.8.0 added the new pycodestyle with new rules. Hacking capped it with 4.0.0 version not with the minor version for 3.*.
The new hacking version 3.0.1 is released which cap the flake8<3.8.0. Thanks to dtantsur and stephenfin for tacking care of it.
To fix your pep8 job you can,
- Either fix the pep8 error in code if easy and fast to fix.
- Or bump the hacking minimum version to 3.0.1. I have proposed it for a few projects failing pep8. - https://review.opendev.org/#/q/topic:hacking-fix+(status:open+OR+status:merg...)
If pep8 job is passing then you do not need to do anything. The existing hacking version cap will work fine.
-gmann
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:
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
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. -gmann
-Brian
On Tue, 2020-05-12 at 12:23 -0500, Ghanshyam Mann wrote:
---- On Tue, 12 May 2020 12:00:11 -0500 Brian Haley <haleyb.dev@gmail.com> wrote ----
On 5/12/20 12:25 PM, Sean McGinnis wrote:
On 5/12/20 11:14 AM, Ghanshyam Mann wrote:
Hello Everyone.
You might have noticed that few or most of the projects pep8 job started failing.
That is because flake8 new version 3.8.0 added the new pycodestyle with new rules. Hacking capped it with 4.0.0 version not with the minor version for 3.*.
The new hacking version 3.0.1 is released which cap the flake8<3.8.0. Thanks to dtantsur and stephenfin for tacking care of it.
To fix your pep8 job you can,
- Either fix the pep8 error in code if easy and fast to fix.
- Or bump the hacking minimum version to 3.0.1. I have proposed it for a few projects failing pep8. - https://review.opendev.org/#/q/topic:hacking-fix+(status:open+OR+status:merg...)
If pep8 job is passing then you do not need to do anything. The existing hacking version cap will work fine.
-gmann
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:
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
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.
just in case it was nto seen from my minimal testing if i create a tox env with master. then i downgrade both flake8 and pycodestyle in the virtual enve the nova tests still fail. do i need to explcitly down grade hacking too? .tox/venv/bin/pip install -U pycodestyle\<2.6 flake8\<3.8 and re running the test is failing for me even if i do find -name *.pyc -delete to make sure there are no .pyc files cached anywhere
-gmann
-Brian
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:
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
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
---- On Tue, 12 May 2020 13:07:43 -0500 Brian Haley <haleyb.dev@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:
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
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
---- On Tue, 12 May 2020 14:43:07 -0500 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----
---- On Tue, 12 May 2020 13:07:43 -0500 Brian Haley <haleyb.dev@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:
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
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.
If your project is using flake8-import-order plugin then also we need to cap pycodestyle explicitly. flake8-import-order does not cap pycodestyle and pull the latest pycodestyle, I have proposed PR there at least to be safe for the future version. - https://github.com/PyCQA/flake8-import-order/pull/172 -gmann
-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
---- On Tue, 12 May 2020 22:14:28 -0500 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----
---- On Tue, 12 May 2020 14:43:07 -0500 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----
---- On Tue, 12 May 2020 13:07:43 -0500 Brian Haley <haleyb.dev@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:
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
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.
If your project is using flake8-import-order plugin then also we need to cap pycodestyle explicitly. flake8-import-order does not cap pycodestyle and pull the latest pycodestyle, I have proposed PR there at least to be safe for the future version.
hacking 3.1.0 is released now which will bring flake8 3.8.0 new chekcs. So if pep8 job is failing on your repo then, merge the already proposed patch which cap hacking >=3.0.1 <3.1.0. I have proposed the patches and should be ready to merge. And later you can fix the code and adopt new hacking 3.1.0 whenever you want to do but that is not urgent. -gmann
-gmann
-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
---- On Tue, 12 May 2020 11:25:14 -0500 Sean McGinnis <sean.mcginnis@gmx.com> wrote ----
On 5/12/20 11:14 AM, Ghanshyam Mann wrote:
Hello Everyone.
You might have noticed that few or most of the projects pep8 job started failing.
That is because flake8 new version 3.8.0 added the new pycodestyle with new rules. Hacking capped it with 4.0.0 version not with the minor version for 3.*.
The new hacking version 3.0.1 is released which cap the flake8<3.8.0. Thanks to dtantsur and stephenfin for tacking care of it.
To fix your pep8 job you can,
- Either fix the pep8 error in code if easy and fast to fix.
- Or bump the hacking minimum version to 3.0.1. I have proposed it for a few projects failing pep8. - https://review.opendev.org/#/q/topic:hacking-fix+(status:open+OR+status:merg...)
If pep8 job is passing then you do not need to do anything. The existing hacking version cap will work fine.
-gmann
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:
It will only fail stable/ussuri not older stable as hacking flake8 cap issue is released in hacking 2.0 which is in ussuri. So all other stable branches will be using hacking <1.20 which does not have this issue. having flake8 in project test-requirement also need more maintainance to keep both place (hacking as well as project's test-requirements) in sync otherwise it can break anytime. example: https://review.opendev.org/#/c/727206/ -gmann
---- On Tue, 12 May 2020 12:18:09 -0500 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----
---- On Tue, 12 May 2020 11:25:14 -0500 Sean McGinnis <sean.mcginnis@gmx.com> wrote ----
On 5/12/20 11:14 AM, Ghanshyam Mann wrote:
Hello Everyone.
You might have noticed that few or most of the projects pep8 job started failing.
That is because flake8 new version 3.8.0 added the new pycodestyle with new rules. Hacking capped it with 4.0.0 version not with the minor version for 3.*.
The new hacking version 3.0.1 is released which cap the flake8<3.8.0. Thanks to dtantsur and stephenfin for tacking care of it.
To fix your pep8 job you can,
- Either fix the pep8 error in code if easy and fast to fix.
- Or bump the hacking minimum version to 3.0.1. I have proposed it for a few projects failing pep8. - https://review.opendev.org/#/q/topic:hacking-fix+(status:open+OR+status:merg...)
If pep8 job is passing then you do not need to do anything. The existing hacking version cap will work fine.
-gmann
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:
It will only fail stable/ussuri not older stable as hacking flake8 cap issue is released in hacking 2.0 which is in ussuri. So all other stable branches will be using hacking <1.20 which does not have this issue.
having flake8 in project test-requirement also need more maintainance to keep both place (hacking as well as project's test-requirements) in sync otherwise it can break anytime. example: https://review.opendev.org/#/c/727206/
Or even stable/ussuri for many projects has older hacking so we are safe there. i checked neutron, keystone at least. - https://github.com/openstack/neutron/blob/86b57718966dc2165b4cfb54bcae21b515... So we can backport the hacking min version to only projects have hacking >2.0 cap in stable/ussuri. All older stable branch are safe until projects explicitly having flake8 (in ironic case) or pycodestyle (in neutron case). -gmann
-gmann
participants (4)
-
Brian Haley
-
Ghanshyam Mann
-
Sean McGinnis
-
Sean Mooney