Release master branch on PyPi

[calumy]

The current version of this plugin on PyPi (1.2.1) is not able to run with flake8's current version (5.0.1). This has been fixed in #262 but has not been updated on PyPi. Please could this be done?

[Secrus]

This is a blocker in migrating to new flake8 version

[Secrus]

@sobolevn any chance for a release soon?

[janmayer]

Hello there! A timely release would be highly appreciated. Thanks.

[tobiasraabe]

And, do you also consider removing the upper bound on flake8? You probably have good reasons to do so, but in this instance it felt unnecessarily restrictive and caused a lot of hassle downstream.

For me, pip's dependency resolver did not show flake8-eradicate as the problematic package, but first suggested flake8-docstring, then blamed flake8-alfred, two other packages and then pointed to this package. I assume a couple of people had similar issues.

Here is also a post, https://iscinumpy.dev/post/bound-version-constraints/, which has way more elaborated arguments against upper bound constraints.

Thank you very much for maintaining this useful package!

[Secrus]

And, do you also consider removing the upper bound on flake8? You probably have good reasons to do so, but in this instance it felt unnecessarily restrictive and caused a lot of hassle downstream.

For me, pip's dependency resolver did not show flake8-eradicate as the problematic package, but first suggested flake8-docstring, then blamed flake8-alfred, two other packages and then pointed to this package. I assume a couple of people had similar issues.

Here is also a post, https://iscinumpy.dev/post/bound-version-constraints/, which has way more elaborated arguments against upper bound constraints.

Thank you very much for maintaining this useful package!

I don't think removing the upper bound is such a good thing. If plugin API changes for some reason, it may cause unexpected breakage.

[mwgamble]

Upper bounds are there for a reason. I suspect they're not used in the Python world much though for a couple of reasons:

• packages are generally a bit more stable than we tend to find in the javascript world
• specifying lower and upper bounds for the same package is not easy
  • it's easier now with the ability to use the ^ marker with poetry, but a lot of packages aren't using poetry
• general lack of awareness

FWIW I believe it's important to specify upper bounds.

[GsakuL]

@mwgamble

* specifying lower and upper bounds for the same package is not easy
  * it's easier now with the ability to use the `^` marker with poetry, but a lot of packages aren't using poetry

what do you mean "not as easy"? Poetrys ^ is just a shorthand for an explicit (inclusive) lower and (exclusive) upper bound. The first example from poetry (https://python-poetry.org/docs/dependency-specification/): ^1.2.3 would be the same as >=1.2.3,<2.0.0. It is "foolproof" (upper bound not below lower bound) and convinient. But Poetry and pip (https://peps.python.org/pep-0440/#version-specifiers) understand the comma separated versions. (Also the "explicit"/long/compound version may be easier to understand at first glance, as to what it does.)

[jonyscathe]

@Secrus, the flake8 package is very well maintained and it is very unlikely that there will be any breaking API changes without DeprecationWarnings popping up for a few releases before the breaking change happens.

@mwgamble this has a good description as to why upper bounds are used less in Python compared to Javascript: https://iscinumpy.dev/post/bound-version-constraints/#technical-difference Having upper bounds can cause large issues if packages then have conflicting requirements (which I currently have, as some other flake8 extensions now have a lower bound of >5.0.0) which then make the pip solver do a whole lot of extra work - which is slow and potentially (often) does the wrong thing, often finding old buggy versions of libraries that don't have any bounds. IMO it is one of the big issues with python...

That being said, I generally don't hate upper bounds when used selectively. If any flake8 extension is relying on undocumented features or any particular internal flake8 behaviour then they should have an upper bound on flake8. But simple flake8 extensions probably don't need them. And any packages with a upper bound on flake8 should be prepared to do a new release pretty quickly after any flake8 major release, especially as it is likely that some random person will do a PR/testing for the new flake8 version. Otherwise you start getting threads like this popping up :D

[danyeaw]

Hi all, thanks for the awesome library. Could we please have an update on when a new release is supposed to made?

:100: to everything @jonyscathe just said. I have had dependabot failing PRs for 9 days now on my open source projects.

[janmayer]

@sobolevn any chance to get a new version tagged and on pypi this week?

[sobolevn]

Hi! New version is released: https://github.com/wemake-services/flake8-eradicate/releases/tag/1.3.0

If any of you want to support further development of this project, consider:

1. https://github.com/sponsors/wemake-services
2. https://opencollective.com/wemake-python-styleguide

🙂

[mwgamble]

I have had dependabot failing PRs for 9 days now on my open source projects.

I recommend switching to Renovatebot. It wraps up dependency updates into a single PR, rather than spamming your project with one update per dependency. It also doesn't automatically operate on forks, so it's more friendly for external contributors.