Poetry: Add ability to append build number to version identifier at build time

[TheFriendlyCoder]

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

Feature Request

Currently, poetry assumes / forces you to define your product version number explicitly in the pyproject.toml file. This is fine for building releases but doesn't work well when building pre-releases since such builds typically share the same target version. To avoid name/version clashes between packages, poetry should have some way to append a build number to the final package version at build time.

When using setuptools this is typically handled by appending a suffix such as dev or alpha followed by some sort of unique identifier such as a timestamp or build number. I'd like to see something similar in poetry.

What I thought might work best is to add an optional suffix parameter to the poetry build command which, when provided, would be appended to the version identifier stored in the the toml file. So if the static version in the toml file were, say, "1.0.0" and you ran poetry build --version_sufix = ".dev$BUILD_ID" or something similar, then the generated package would be versioned as "1.0.0.dev1234" (where "1234" is the current build number as defined by the environment variable BUILD_ID).

[TheFriendlyCoder]

NOTE: this feature enhancement is one of but a few fundamental problems that are currently blocking my team from adopting poetry as a full package replacement tool for all of our projects. In the absence of this feature - or something similar - we can not facilitate cross-developer builds where each developer is working on the same project release but on different branches. Each build needs to be uniquely labelled / addressable otherwise the packages will clash with one another when published to the package repository.

All this to say, this is a relatively high priority improvement for us.

[TheFriendlyCoder]

I probably also should mention that I am willing to put some effort into implementing this feature and submitting a pull request if the project maintainers don't have enough time to implement this in the near future. I'd just like to make sure the feature makes sense to the community as a whole before putting in the effort.

[areeh]

We have to work entirely around development wheels right now, so this would be useful.

I'm curious about the choice of arbitrary suffix string, or if you wanted to default to a suffix with compatibility with the rest of the world: The .devN suffix agrees with pep440 and pip. What about poetry itself? Perhaps this part of the source is relevant.

[asodeur]

I'd think this is the most wanted use-case for #693. Once this has landed it should not be long until setuptools-scm/versioneer-style plugins arrive. There have been tons of requests in that direction #5, #185, #672, #1034 and probably a lot more people waiting for this on the side-lines.

[dsully]

Ideally having an option to pass the version to the build command. We maintain dynamic versions that are centrally stored. I'd want to pass that version along to the build and have it embedded in the resulting sdist and wheels.

[mtkennerly]

It's technically possible to do this by running poetry version $VER before poetry build, but you'd need a script that can pass the right version to the command. I actually wrote a pseudo-plugin for Poetry for this specific use case, if you'd like to try it. The implementation is a hack until #693 is available \:p

[HitLuca]

For anyone interested in using poetry with some basic automatic versioning, check out this past PR that was proposed, but declined in favor of a future plugin-based component.

[SailingYYC]

Looking for something quite similar to be able to update the version dynamically at build, but without it being reflected inpyproject.toml.

[Yajing-Zhao]

NOTE: this feature enhancement is one of but a few fundamental problems that are currently blocking my team from adopting poetry as a full package replacement tool for all of our projects. In the absence of this feature - or something similar - we can not facilitate cross-developer builds where each developer is working on the same project release but on different branches. Each build needs to be uniquely labelled / addressable otherwise the packages will clash with one another when published to the package repository.

All this to say, this is a relatively high priority improvement for us.

Hi @TheFriendlyCoder, I had the same feature request and came across your post. I understand why this stops you from adopting poetry. I wonder if you can share your current solution to this problem?

Thanks!

[WhyNotHugo]

I wonder if you can share your current solution to this problem?

Personally, I use setuptools-scm, which generates a version at build-time based on git metadata.

[sinoroc]

This might need the "_Plugins_" label.