commitizen-tools
Discussion on check-consistency
Description
Hi,
I've doubt on how check-consistency flag works.
Steps to reproduce
- have a project managed with poetry, with a pyproject.toml like the following
[tool.poetry]
name = "cool_proj"
version = "2.5.7" <<<< this is mandatory for poetry to make the package
...
[tool.commitizen]
name = "cz_conventional_commits"
version = "2.5.2" <<<< this is mandatory for commitizen
version_files = [
"cool_proj/__init__.py:__version__",
"pyproject.toml:version"
]
and __init__.py contains
__version__ = "2.5.2"
- run
poetry run cz bump --check-consistency
Current behavior
the command works, it prints on stdout
Bump version: 2.5.2 -> 2.5.3 <<< it takes the value from commitizen's toml section
tag to create: 2.5.3
Desired behavior
the expected could be a warning about version not consistent, because at least content of __init__.py differ from the expected (the one into commitizen's toml section).
looking at implementation, also the regex usage has major drawback in this kind of setup, because the regex surely find commitizen's "version" attribute, but it can miss the poetry's one, creating package with wrong number (it's taken from poetry section).
Screenshots
No response
Environment
- commitizen 2.34.0
- python 3.9.13
- windows 11
In the current design, we're not able to check inconsistency with the same format in the same file. (e.g., pyproject:__version__ can be interpret as the one in poetry section or the one in commitizen section.) This is what we do this check. Might need sometime to come up with a new check method 🤔
a cool improvement could be using "dedicated parser" for each supported file format (toml, yaml, json...) , reverting to actual regex way in case dedicated parser does not exist, but this could be breaking in the way version_files is actually wrote (see below).
I mean, for example, using a dedicated toml parser to load and write pyproject.toml, on my use case I should have written:
version_files = [
"cool_proj/__init__.py:__version__",
"pyproject.toml:tool.poetry.version"
]
In this way all the other "version" field into toml file, if any, must not be changed, because there is a perfect reference to the only fields I want to change (tool.poetry.version, this dot notation is put as example, another separator could be used).
Furthermore, in this way, also the check-consistency could benefit (the keys are explicit, all the values must match to proceed).
This sounds to be a great solution. But I'm a bit worried about the maintenance cost and inconsistency between each format. @woile What do you think?
I agree with @Lee-W , I think the current pattern is flexible enough. If you go on the route to support each extension (which is an endless route), it will become a huge burden to maintain. We'd like the tool to remain as general as possible and support any file. A possible regex that solves this could be:
version_files = [
"cool_proj/__init__.py:__version__",
"pyproject.toml:\[tool\.poetry\][.\s\D]*^version"
]
Which would match this toml properly:
[tool.poetry]
name = "foo"
version = "1.2.3"
[tool.commitizen]
version = "1.2.3"
In my experience most of the time doing ^version has been enough, and I haven't used check-consistency much.
I do agree the check-consistency is problematic for this case. But in a way if you have commitizen and poetry under the same toml and your regex is pyproject.toml:^version, the regex pattern will pick any of the present words, because that's what we are telling it to do. I think one option is to use .cz.toml or go for a stronger regex.
