Closed staticdev closed 2 years ago
I understand the argument against freezing major numbers, but I disagree. Semantic versioning states it pretty explicitly for the major version number,
MAJOR version when you make incompatible API changes,
While Python may not follow semver, it's close enough. Darglint will almost certainly not work in Python 4.0, if that ever arrives. My personal philosophy is that while version numbers don't guarantee that a library will/won't work for a given version, they should communicate the versions for which the library are most likely to work.
@terrencepreilly I understand your point, but do you see any negative effect to your project if you accept the PR I provided?
I am using a cookiecutter with almost 30 dependencies and currently Darglint is the ONLY one that constrains the packages using it to Python <4.0. It is a lib I value a lot, I would not like to remove it from my templates to fulfil non-restricted dependencies major python.
do you see any negative effect to your project if you accept the PR I provided?
Version constraints aren't present for the benefit of a library per se. They're for the benefit of projects depending on them. If the Python foundation decides to release python 4 a year from now, then darglint could (and probably would) fail in non-obvious ways. Which could be a minor headache for someone else to figure out, especially if it were far down in a dependency chain.
@terrencepreilly the main problem is that a growing number of python projects use Poetry that will not allow the resolution of many projects using darglint due to this restriction. And the restriction is not actually based in a version of python you KNOW will not work. It is not a big deal for you to remove and will enable more projects to use/keep using this great tool you have.
I myself have more than a dozen projects using it and unfortunately with growing dependency to how Poetry works am considering to drop it.
It is not possible for instance to create a project that uses darglint and require python>=3.8 for instance. Solver will have a message like:
It would be nice to soften this requirement, since there is no real information that shows darglint will stop working on python 4.0.
There is an extensive article with ideas of why one should not limit that: https://iscinumpy.dev/post/bound-version-constraints/