setuptools_scm always bumps version

[captivus]

Hello! I'm struggling to get setuptools_scm to just lift the latest git tag as the version number and not bump it automatically every time. I'm not sure if this is a reportable issue, or just something silly I'm missing. The workflow is as follows:

• Commit changes to local git repo git add . && git commit -am 'commit message here.'
• Tag commit git tag -a v0.0.13 -m 'release 0.0.13'
• Push tag to remote (GitHub) repo git push --follow-tags

Parameters in the pyproject.toml file for setuptools_scm:

[tool.setuptools_scm]
write_to = 'src/mlsgrid_api/_version.py'
local_scheme = 'no-local-version'
version_scheme = 'post-release'

For what it's worth, I added these scheme parameters after setuptools complained that the default (no) parameters didn't produce a PEP 440 compliant version number and wouldn't build.

The result is a version v0.0.13post0. I've Google my fingers raw trying to figure out what I'm doing wrong, and so I'm coming to the source. Is it the workflow I've described above, or is this a bug?

Any help is appreciated!

Cheers.

[RonnyPfannschmidt]

1. Is your version file in git ignore + deleted
2. Does your release process changes files?

Ps, it's strongly recommended not to use post release, the scheme will eventually be deprecated

[captivus]

Thanks for coming back so quickly!

1. The version file is included in the repo. See here. Also, it's worth noting that I can't seem to keep the version in the file and the tag number synchronized due to this same issue. (_version.py, which is updated only by setuptools_scm, notes v0.0.12post0 whilst the build that was deployed to PyPI upon pushing the tag is v0.0.13post0.
2. As I'm having setuptools_scm write to the version file, and I can't manage to keep version numbers in sync with tags due to this issue, it seems that the build process changes the _version.py file each time I release to PyPI.

Re your PS, I'm happy to dump the post release scheme when I get this sorted. It's the only way I've managed to deploy from my pipeline automatically thus far.

[RonnyPfannschmidt]

Basically delete the version file from git if you want setuptools_scm to manage it, else it's changing it all the time

I believe it may be necessary to error out if the version file is git tracked

[captivus]

Thanks for the response!

I added the version file in the first place because setuptools was complaining about my pyproject.toml file in that it has to have a version= declaration in the [project] section. My initial motive for using setuptools_scm is to avoid managing version numbers in multiple places and just do so from my GitHub repo, using tags. The version= requirement was satisfied by adding the following in pyproject.toml:

• This dynamic statement for version=
• These 2 lines in [tool.setuptools.dynamic]
• The write_to = directive so that the dynamic version above is actually an attribute of the package.

This was the only way I could figure out how to get this to work, though it seems probable that I'm doing something wrong.

How should this be done per your guidance?

[captivus]

Rightho! A quick update before I hope on a plane.

Firstly -- thank you @RonnyPfannschmidt for your prompt attention today!

I think I have managed to sort this out with the following approach.

• Delete _version.py
• Delete the write_to= directive in [tool.setuptools_scm] section of the TOML file
• Keep the dynamic = ['version'] declaration in the TOML file
• Change the dynamic reference lookup thusly

I've just pushed the latest version tag (v0.0.14) to my repo and it's successfully been built by my pipeline and deployed to PyPI.

Is there somewhere in the documentation for setuptools_crm that I could submit a pull request to clarify this so as to help others who come after me?

[RonnyPfannschmidt]

The docs folder for detail documentation has not been created, it's somewhere on my within the next half year list,

[captivus]

No worries. Thanks again for your help!

[ptth222]

I was having this same issue, and the cure was as Ronny said. Add _version.py to your gitignore and delete it. I would recommend adding a blurb about this for write_to. Something like "This parameter will likely result in unexpected behavior if you do not add the file to your gitignore."

[RonnyPfannschmidt]

closing after #880 is merged now