)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"5b33c6f0c00ad62f8b6e4720995a4c24ebfbfcfc","unresolved":true,"context_lines":[{"line_number":16,"context_line":"    (which os-brick wants)"},{"line_number":17,"context_line":"- pytz 2013.6 -\u003e 2015.7 (u-c allows 2020.1)"},{"line_number":18,"context_line":"  * needed for babel"},{"line_number":19,"context_line":"- remove pycodestyle from test-requirements (let hacking request"},{"line_number":20,"context_line":"  flake8 which will request the pycodestyle version it wants)"},{"line_number":21,"context_line":"- requests 2.14.2 -\u003e 2.19.0 (u-c allows 2.23.0)"},{"line_number":22,"context_line":"  * oslo-config wants \u003e\u003d2.18, but 2.19.0 doesn\u0027t use idna (which"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"a56c912a_09414e6f","line":19,"updated":"2021-01-07 15:09:42.000000000","message":"Doesn\u0027t this mean that a new release of pycodestyle can suddenly result in new rules being applied?  I thought this was the reason for having it in test-requirements.","commit_id":"1ffde6b3cced79890b135d95841fc0fafecef049"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"0a2d67f4e62975d6381de598902a12cf2c261190","unresolved":true,"context_lines":[{"line_number":16,"context_line":"    (which os-brick wants)"},{"line_number":17,"context_line":"- pytz 2013.6 -\u003e 2015.7 (u-c allows 2020.1)"},{"line_number":18,"context_line":"  * needed for babel"},{"line_number":19,"context_line":"- remove pycodestyle from test-requirements (let hacking request"},{"line_number":20,"context_line":"  flake8 which will request the pycodestyle version it wants)"},{"line_number":21,"context_line":"- requests 2.14.2 -\u003e 2.19.0 (u-c allows 2.23.0)"},{"line_number":22,"context_line":"  * oslo-config wants \u003e\u003d2.18, but 2.19.0 doesn\u0027t use idna (which"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"b6001cb6_adc4fbdd","line":19,"in_reply_to":"a56c912a_09414e6f","updated":"2021-01-08 20:09:25.000000000","message":"Well, we use pycodestyle via flake8 via hacking.  Each flake8 release specifies pycodestyle in requirements so that only new patch versions of pycodestyle are allowed [0], which supposedly means that there won\u0027t be any new checks (just bugfixes) in what flake8 is using.  Since we don\u0027t specify flake8 ourselves in test-req, but let hacking constrain it, I figured we would be OK doing the same with pycodestyle.\n\nBut ... the patch to master didn\u0027t do this, it left pycodestyle\u003d\u003d2.6.0 in test-req.  And I re-ran this locally with the new pip resolver and adding pycodestyle back, and there was no problem.\n\nLet me know what you think.  If we do go with the current patch, we should go back and remove pycodestyle pinning from master.  FWIW, nova doesn\u0027t specify a pycodestyle version, they just specify hacking.\n\n\n[0] https://flake8.pycqa.org/en/latest/faq.html#why-does-flake8-use-ranges-for-its-dependencies","commit_id":"1ffde6b3cced79890b135d95841fc0fafecef049"}]}