Relax version specification for dependencies following semver

[nejch]

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

	questionary = "^1.4.0"
	decli = "^0.5.2"
	colorama = "^0.4.1"
	termcolor = [
	{ "version" = "^1.1", python = "< 3.7" },
	{ "version" = ">= 1.1, < 3", python = ">= 3.7" },
	]
	packaging = ">=19"
	tomlkit = ">=0.5.3,<1.0.0"
	jinja2 = ">=2.10.3"
	pyyaml = ">=3.08"
	argcomplete = ">=1.12.1,<2.2"
	typing-extensions = "^4.0.1"
	charset-normalizer = ">=2.1.0,<3.1"

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

[woile]

I'm open to the suggestion, I think it's a good idea.

[jakob-keller]

I'll prepare a PR this weekend

[nejch]

Awesome! 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 🙇

[jakob-keller]

I just created a draft PR. Feel free to continue the discussion over at #684

[jakob-keller]

I just created a draft PR. Feel free to continue the discussion over at #684

The minimal PR is ready, IMO.