Incorrect version number in the latest tag

[avalentino]

The version in the pyproject.toml file in the latest tag (v0.0.81) is 0.0.0.dev0.
This seems to be not in line with the source distribution published in pypi.
Is this expected?

[michalc]

It is expected yes.

The 0.0.0.dev0 is replaced by the release process just before publish to pypi https://github.com/uktrade/stream-zip/blob/main/.github/workflows/deploy-package-to-pypi.yml#L19. Have to admit I've not seen this done elsewhere, but it makes releasing new versions very straightforward: we make a release in GitHub with no code change involved.

Is this causing a problem? (/do you have a better way?)

[avalentino]

I'm packaging stream-zip for debian and the generated package has the version number that is in the pyproject.toml file, the incorrect one.

The current workaround is to patch the sources I would like to avoid to do it in the long term.

The option of using directly the source tarball in pypy (rather then the one in the github tag) is also problematic for me because the pypi tarball does not include, e.g., the test suite.

[michalc]

Ah I think understood… Will have a ponder on how best to approach this - I am quite keen to avoid having to manually change the version in code each time though, but also I have liked the ease at which I can just make a GitHub release and PyPI is automatically deployed to

[michalc]

Actually a question: do you have to take the code from a tag, or could you take from another asset from releases: https://github.com/uktrade/stream-zip/releases

So we can do any faffing with the version in code at our end rather than yours

[avalentino]

Using releases should be fine

[michalc]

After a few false starts, now have a "Source code (with release version)" asset in new releases which is all of the source code, but with the correct version in pyproject.toml, e.g. at https://github.com/uktrade/stream-zip/releases/tag/v0.0.82

[avalentino]

Thanks a lot @michalc
I have just tested the packaging of the new release and all works perfectly without patching the version number.
Closing

[stuaxo]

In Shoebot when we had a similar thing with versions, I ended up adding a unit test that failed if the versions wheren't synced (not pyproject.toml there, but setup.py as our project is old)