mtkennerly / poetry-dynamic-versioning

Plugin for Poetry to enable dynamic versioning based on VCS tags
MIT License
607 stars 35 forks source link

tool.poetry.version field is not updated #182

Closed steven-douilliet closed 3 months ago

steven-douilliet commented 4 months ago

Hello,

When I run the poetry build command, the tool.poetry.version field is not updated and remains at 0.0.0 (placeholder). While the source and wheel archives are correctly versioned, as well as __version __ and __version_tuple __.

See below my config:

[tool.poetry]
...
version = "0.0.0"
...

[tool.poetry-dynamic-versioning]
enable = true
vcs = "git"
format = "{base}"
style = "semver"
latest-tag = true
bump = true

[tool.poetry-dynamic-versioning.files."private/__init__.py"]
persistent-substitution = true
initial-content = """
__version__ = "0.0.0"
__version_tuple__ = (0, 0, 0)

__all__ = (
    "__version__",
    "__version_tuple__",
)
"""

[build-system]
requires = ["poetry-core>=1.0.0", "poetry-dynamic-versioning>=1.0.0,<2.0.0"]
build-backend = "poetry_dynamic_versioning.backend"
mtkennerly commented 4 months ago

the tool.poetry.version field is not updated and remains at 0.0.0

Are you referring to the pyproject.toml inside of the sdist/wheel or the pyproject.toml in your working folder? The plugin temporarily changes the version field in your working folder's pyproject.toml so that it's included in the sdist/wheel, but then reverts it so that you don't accidentally commit it. Could you confirm the content of the sdist/wheel's pyproject.toml?

steven-douilliet commented 4 months ago

I'm referring to the pyproject.toml inside my working folder. dist/ content:

dist/
├── private-0.1.0-py3-none-any.whl
└── private-0.1.0.tar.gz

0 directories, 2 files

I don't understand why update the __version__ and __version_tuple__ variables but not the tool.poetry.version field? So we need to manually update the tool.poetry.version field against the __version__ content?

mtkennerly commented 4 months ago

Just to be clear, if you extract the whl and tar.gz files, you'll see that they contain a copy of pyproject.toml where the version field is set to the dynamic version as expected.

This plugin primarily ensures that your build artifacts will contain the dynamic version. The local state in your working folder is (by default) only adjusted temporarily in order to help generate those build artifacts correctly. The changes to __init__.py are only remaining in place because you've set the persistent-substitution flag - otherwise, those would be cleaned up as well.

It is possible to leave all changes in the working folder by running poetry dynamic-versioning, but this is mainly for testing/debugging, not something you'd normally need to use. Could you elaborate on your use case for wanting the changes left in the working folder?

steven-douilliet commented 3 months ago

Thank you for your explanation. I understand the purpose of the plugin better.

When I want to release a new version, I want to use the plugin to automatically update the version (in tool.poetry.version, __version__ and __version_tuple__) and commit changes on git (before merging on main branch)

mtkennerly commented 3 months ago

Could you elaborate on why you want to commit the changes? I'm wondering if this is an XY problem. What problem do you want to solve by committing the changes, instead of letting the plugin temporarily set the version as needed?