Make version in `pyproject.toml` optional, or at least validate it *after* the plugins are run

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

Thanks for Poetry! I’m a big fan. 🎉

I wanted to be able to keep my package versions in __init__.py, and with the new alpha supporting plugins I was able to create a plugin to read the version from it dynamically: https://github.com/tiangolo/poetry-version-plugin

But currently, Poetry checks and verifies if the version is set in pyproject.toml, and if it is not set there, it terminates with an error.

That means that even though the plugin is taking care of setting the package version, a dummy “version” is required in pyproject.toml, even though it is not really used.

My feature request is to make the version field optional in pyproject.toml.

Or alternatively, check if the version is set in the Poetry object in memory after running the plugins. That way my plugin can set the version.

Motivation

If users try to use that plugin (or any other similar one), they would have to set a version just to trick Poetry into thinking the pyproject.toml has all the fields, while the version is not really used in the end. So, for the final result, it’s an extra workaround step.

[pbarker]

@Conchylicultor I wonder why that’s the case. Wouldn’t running an automated version bump, e.g. poetry version $(poetry version --short)-nightly-$(date ‘+%s’), help with your use case?

I also have this problem but poetry version won’t solve it because we primarily install Python packages from git. This saves us the overhead of needing a private PyPi.

In the software world I am engaged with, using git versioning as the source of truth is best practice. Deviating from the git revision is only advised if the git revision is somehow lacking (rare). Idea being git is the root-most version, and we don’t want to complicate the system needlessly.

This is a perfectly rational approach to versioning python packages and it would be great if Poetry could support it. No breaking change required, version could just be made optional. Ideally, Poetry would default to the git revision if version not present without a plugin, but needing one would be fine too.

[dbanty]

FWIW I, too have encountered issues with using importlib.metadata with Poetry. Specifically for FastAPI apps, I want to have the version of the package available to the server at runtime so it shows up in the docs & OpenAPI document. Unfortunately, poetry install seems to be capable of retaining multiple versions of the same package. This lead to an issue in CI where restoring a cached virtualenv to build & deploy would actually sometimes grab the wrong version number from importlib.metadata 😨 .

This is probably a niche edge case, as the version is for an app, not a published library… but it’s a real world example of the importlib method not working. Our solution was to parse pyproject.toml manually, grab the version number from it, and inject that into a separate version.py in the build process which is… messy and clunky to say the least 😓. Having a source of truth which is always available to the Python code at runtime (e.g. __version__ in __init.py__) would have made that much cleaner.