Repository navigation
Discussion on check-consistency #595
Description
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
Activity
Lee-W commentedon Sep 23, 2022
Thanks for your report! I've verify this error on my local machine
Lee-W commentedon Sep 23, 2022
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 🤔gpongelli commentedon Sep 25, 2022
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_filesis 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:
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).
Lee-W commentedon Sep 26, 2022
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?
woile commentedon Sep 26, 2022
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:
Which would match this toml properly:
In my experience most of the time doing
^versionhas been enough, and I haven't used check-consistency much.I do agree the
check-consistencyis problematic for this case. But in a way if you havecommitizenandpoetryunder the sametomland your regex ispyproject.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.tomlor go for a stronger regex.bearomorphism commentedon May 9, 2026
Triage from #1964: Confirmed still valid on master (4.15.1).
--check-consistencyonly validates files listed inversion_filesagainst the commitizen-config version. If yourpyproject.tomlhas[tool.poetry].versionand you don't addpyproject.toml:^versiontoversion_files, the poetry version isn't checked. Long-term fix idea: whenversion_provider = "poetry"(orpep621), the provider's source could be auto-included in the consistency check.bearomorphism commentedon May 9, 2026
Verification update (re #1964)
Reproduced against current master (4.15.1):
Config: poetry-managed
pyproject.tomlwith[tool.poetry].version = "2.5.7"(out of sync) and[tool.commitizen].version = "2.5.2". Listed bothcool_proj/__init__.py:__version__andpyproject.toml:versioninversion_files.cz bump --check-consistency --yesexits 0 with no warning, bumping from commitizen's2.5.2:Final state:
pyproject.tomlhas[tool.poetry].version = "2.5.7"(unchanged) and[tool.commitizen].version = "2.6.0"— still mismatched.Verdict: STILL VALID.
--check-consistencyonly validates thatversion_filesregex matches found the cz-config version; it doesn't compare values across distinct version sources. Possible improvements:version_provideris set (e.g.,poetry,pep621), have--check-consistencycross-check the provider's source against the cz-config version.version_filesregex onpyproject.toml:versionwill match the firstversion =line — which can be poetry's, not commitizen's — so the check is not what users expect.