Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: use Poetry as Commitizen version provider #215

Merged
merged 1 commit into from
Feb 22, 2024

Conversation

sinopeus
Copy link
Collaborator

@sinopeus sinopeus commented Feb 21, 2024

Using Poetry as the version provider source will specifically get and set the version using the tool.poetry.version field in pyproject.toml, as described here.

This has two advantages:

  1. We only have to keep track of the project version in one place in pyproject.toml.
  2. We avoid bugs that can result from the "naive" way that cz bump works when using version_files instead of version_provider. When bumping the version, it will replace all instances of the current version string in pyproject.toml with the new version string. This can cause bugs when certain dependencies coincidentally have a version constraint which contains the current version string as a substring. When this happens, it results in an inconsistent state between pyproject.toml and poetry.lock.

Here is an occurrence of this bug as reported by one of our users:

I tried to bump the version of my project from 0.2.1 to 0.2.2, but cz bump not only changes the version = "0.2.1" line under the [tool.commitizen] heading, but also the version of a dependency called kaleido, which happens to also be constrained to >=0.2.1, which causes it to error on the fact that the poetry.lock isn't up to date with the pyproject.toml anymore, leaving the project in an inconsistent state.

@sinopeus sinopeus self-assigned this Feb 21, 2024
@sinopeus
Copy link
Collaborator Author

All credits to @jorenverspeurt for discovering the nasty bug described above. I classified this as chore but it could be fix as well, @lsorber you can change the prefix if you'd like 🙂

Using Poetry as the version provider source will specifically get and set the
version using the `tool.poetry.version` field in `pyproject.toml`, as described
[here](https://commitizen-tools.github.io/commitizen/config/#version-providers).

This has two advantages:

1. We only have to keep track of the project version in one place in
`pyproject.toml`.
2. We avoid bugs that can result from the "naive" way that `cz bump` works when
using `version_files` instead of `version_provider`. When bumping the version,
it will replace all instances of the current version string in `pyproject.toml`
with the new version string. This can cause bugs when certain dependencies
coincidentally have a version constraint which contains the current version
string as a substring. When this happens, it results in an inconsistent state
between `pyproject.toml` and `poetry.lock`.

Here is an occurrence of this bug as reported by one of our users:

"""
I tried to bump the version of my project from 0.2.1 to 0.2.2, but `cz bump`
not only changes the `version = "0.2.1"` line under the [tool.commitizen]
heading, but also the version of a dependency called `kaleido`, which happens
to also be constrained to >=0.2.1, which causes it to error on the fact that
the `poetry.lock` isn't up to date with the `pyproject.toml` anymore, leaving
the project in an inconsistent state.
"""
@sinopeus sinopeus force-pushed the xga-fix-version-provider branch from 7ec63eb to 0edd154 Compare February 21, 2024 14:16
@lsorber lsorber changed the title chore: Use Poetry as Commitizen version provider fix: use Poetry as Commitizen version provider Feb 22, 2024
@lsorber lsorber merged commit 59ba878 into main Feb 22, 2024
2 checks passed
@lsorber lsorber deleted the xga-fix-version-provider branch February 22, 2024 08:15
@lsorber
Copy link
Member

lsorber commented Feb 22, 2024

Nice improvement, thank you @sinopeus! And good catch @jorenverspeurt, that must have been difficult to track down.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants