Repository navigation
Relax version specification for dependencies following semver #683
Description
Activity
I'm open to the suggestion, I think it's a good idea.
Reacted by Nejc HabjanI'll prepare a PR this weekend
Reacted by Nejc Habjan and Santiago Fraire WillemoesAwesome! I see that termcolor (for py3.7+), packaging, jinja2, pyyaml are already open for higher versions. Perhaps this can be the case for all of them, unless testing runs into issues (so maybe pin them with a lockfile for testing only, and maintain it with dependabot/renovate, but not lock the versions for dependent users).
Also, typing-extensions could probably be limited to specific python versions (depending on what's needed, might even be 3.7 only, I haven't looked at the code).
I also see that charset-normalizer was maybe not intentionally pinned to a specific minor version but for the same reason as already discussed (309a409).
Thanks again for the quick responses 🙇
Reacted by Santiago Fraire WillemoesI just created a draft PR. Feel free to continue the discussion over at #684
I just created a draft PR. Feel free to continue the discussion over at #684
The minimal PR is ready, IMO.
Description
Currently quite a few prod dependencies are defined in very strict ranges, even though commitizen is likely to be installed more as a library along with other dependencies rather than a single application. See:
commitizen/pyproject.toml
Lines 60 to 73 in fb0d1eb
Partially I would blame poetry's default behavior for adding dependencies, which is more restrictive than you'd really want for libraries IMO. So I'd personally use PEP-440 specifiers here rather than poetry's custom caret versioning.
For dependencies that reliably follow semver, I think it's not an issue to at least allow the current major version, or even open it up completely and restrict versions only when there are issues, which is more common in python IMO (this is not npm so we cannot have multiple versions of transitive dependencies at the same time.. so we kind of have to be a bit more broad with ranges to make life easier).
/cc @jakob-keller
Possible Solution
Check the current production dependencies and see if they follow semantic versioning. If they do, assume good intentions and lock only major versions for those ;)
Additional context
No response
Additional context
#680