BUG: poetry-dynamic-versioning settings for poetry-pyinstaller-plugin

[comalice]

Please see thmahe/poetry-pyinstaller-plugin#54 for discussion.

Summary

poetry-pyinstaller-plugin fails to use the correct version string when tool.poetry-dynamic-versioning.metadata is unset or true.

Solution

Ensure tool.poetry-dynamic-versioning.metadata = false. The eliminates the git hash from the version string making it PEP440 compliant. This allows poetry-pyinstaller-plugin to use the version string.

Example

https://github.com/comalice/python_dynamic_version_and_pyinstaller

[mtkennerly]

Hi! I imagine there may be an issue here with the order that Poetry activates the plugins and/or if poetry-pyinstaller-plugin doesn't read from the same internal state that poetry-dynamic-versioning updates.

I followed your repro steps up to creating the first tag. Even without making any other changes, I see this, where the other plugin uses 0.0.0:

$ poetry build
Preparing PyInstaller 6.14.0 environment C:\tmp\pyinst\.venv
  - Installing textual (>=3.2.0,<4.0.0)
Building binaries with PyInstaller Python 3.10 [win_amd64]
  - Building app-name SINGLE_FILE
  - Built app-name-0.0.0 -> 'dist\pyinstaller\win_amd64\app-name-0.0.0'
Building app-name (1.0.0)
Building sdist
Building wheel

For Poetry's internal state, this plugin updates poetry._package._version and poetry._package._pretty_version. It looks like the other plugin checks poetry.pyproject.data["project"]["version"] or poetry.pyproject.data["tool"]["poetry"]["version"].

I could update this plugin to set those fields (it already does in the actual file pyproject.toml, but not in Poetry's internal state). However, if the other plugin loads first, then I don't think it would work anyway, and I don't think there's a way to control plugin load order. You could try submitting a request to the Poetry team to see if they'd consider that feature.