deps: support flake8 v5 #116
Conversation
|
Test case on my PR run successfully: nhymxu#1 |
- try to work around isort incompatibility while waiting for gforcada/flake8-isort#116
See gforcada/flake8-isort#116 Signed-off-by: Gabriel Linder <linder.gabriel@gmail.com>
.github/workflows/tests.yml
Outdated
| isort: [4.3.21, 5.9.3] | ||
| flake8: [3.9.2, 4.0.1] | ||
| isort: [4.3.21, 5.10.1] | ||
| flake8: [3.9.2, 4.0.1, 5.0.1] |
There was a problem hiding this comment.
flake8 has bumped to 5.0.4, can you update this target and test again, please?
There was a problem hiding this comment.
@nhymxu would you mind applying this suggestion?
There was a problem hiding this comment.
I bump version to 5.0.4
.github/workflows/tests.yml
Outdated
| isort: [4.3.21, 5.9.3] | ||
| flake8: [3.9.2, 4.0.1] | ||
| isort: [4.3.21, 5.10.1] | ||
| flake8: [3.9.2, 4.0.1, 5.0.1] |
There was a problem hiding this comment.
@nhymxu would you mind applying this suggestion?
flake8_isort.py
Outdated
| @@ -10,7 +10,7 @@ | |||
| import warnings | |||
|
|
|||
|
|
|||
| __version__ = '4.1.2.post1.dev0' | |||
| __version__ = '4.2.0' | |||
There was a problem hiding this comment.
Please leave this as it is, when a new release is cut it is automatically handled by zest.releaser
There was a problem hiding this comment.
@gforcada I revert it
| @@ -55,7 +55,7 @@ def get_version(file="flake8_isort.py"): | |||
| include_package_data=True, | |||
| zip_safe=False, | |||
| install_requires=[ | |||
| 'flake8 >= 3.2.1, <5', | |||
| 'flake8 >= 3.2.1, <6', | |||
There was a problem hiding this comment.
maybe we can drop the upper limit? I would say yes
There was a problem hiding this comment.
Hmm, as my view, I think we should keep it.
We don't know about what happend when flake8 bump to version 6.
So I think we need verify again when major change is better.
But if you think remove is okay. I will help remove it.
There was a problem hiding this comment.
It's a good checkpoint, as long as updates come fast enough to account for it.
There was a problem hiding this comment.
I would recommend removing the upper bound, you're just going to have this same scramble every time I release a major version and I'm going to have to deal with the grumpy users every time that report stuff to the wrong place
There was a problem hiding this comment.
The problem seems to be that 3.0.0 of flake8-isort was released without upper bound, so when a new major release of flake8 comes along, that one is dug up by dependency resolution and all bug fixes between 3.0.0 and now are resurfaced. I agree an upper bound is a good checkpoint if it prevents dependencies from being satisfied until the new version is confirmed to be compatible. But when a 2+ year old release surface it is pretty confusing.
There was a problem hiding this comment.
generally I find the best approach for libraries is to only include < when there is a known broken version and even then generally prefer != with the assumption it will be fixed
|
Thanks all, specially @nhymxu for doing the PR and all the feedback from the others, I would like a few changes being made and then I can cut a release 👍🏾 |
|
My PR run successfully all test case. |
|
flake8-isort 4.2.0 is out! 🎉 Please take a minute to try it and report if it works as expected 😄 Thanks for the code contributions and the comments! 💯 |
|
Works for me. Thanks all. |
Close #115