`python_requires` has minor-version upper limit
ErikBjare opened this issue · comments
In setup.cfg:
python_requires = >=3.6.0, <3.9.0
Since Python minor-versions should be backwards compatible, this should probably be:
python_requires = >=3.6.0, <4.0.0
Or better yet:
python_requires = ^3.6
Otherwise, the package is incompatible with packages that simply target ^3.6 to ^3.8 (which should be most).
Unless of course there is a reason, but from looking over the dependencies and my understanding of the code I don't see one.
I now realize I've mentioned this before, in #129 🙂
Yeah, well. This is a bit "philosophical" question. In other requirements that follow SemVer I would say "for sure", but I have a bit different feeling about Python. To my knowledge there is no upcoming "version 4.0" and I have read somewhere from BDFL that it is not something happening anytime soon. So I am more conservative about the support of new Python's versions.
The upgrade should be as simple as PR with adding new version to CI and bump in setup.cfg.
That said my response time might not be the best 😅 So this might not be as fast as I would like. But still, I feel like I want to stay on safe-side and maybe work more on my response times 😁
So closing this for know. Maybe it will be reconsidered later on.
@AuHau It's just weird to set an upper version limit unless you know that there exists a forwards incompatibility when new Python versions are generally backwards compatible except in cases where there are DeprecationWarnings, or hacking around with internals.
I have several repos with hundreds of dependencies each and none of them set python_version as restrictively as you do (the most common thing seems to simply be python-versions = "*" or python-versions = ">=3.5", but some do things like python-versions = ">=3.5, <4").
The problem with what you're currently doing is that it makes the package impossible to depend on for any "version progressive" packages (all packages I know of, except this one). It's for example impossible to use with a default poetry-setup pyproject.toml, so now I've taken to depending on my own fork instead of simply using upstream, which is annoying.
SemVer or not, best-practices should rule.
Hmm that sounds indeed annoying. Ok, lets change the approach to "people will report when it is broken" then.
I will try to incorporate this change when I will be working on the fix of #141
Sorry, it took so long, but should be fixed with the new v2.2.1 release :-) Let me know if there is some problem!