2

Similar questions like this were raised many times, but I was not able to find a solution for my specific problem.

I was playing around with setuptools_scm recently and first thought it is exactly what I need. I have it configured like this:

pyproject.toml

[build-system]
requires = ["setuptools_scm"]
build-backend = "setuptools.build_meta"

[project]
...
dynamic = ["version"]

[tool.setuptools_scm]
write_to = "src/hello_python/_version.py"
version_scheme = "python-simplified-semver"

and my __init__.py

from ._version import __version__
from ._version import __version_tuple__

Relevant features it covers for me:

  • I can use semantic versioning
  • it is able to use *.*.*.devN version strings
  • it increments minor version in case of feature-branches
  • it increments patch/micro version in case of fix-branches

This is all cool. As long as I am on my feature-branch I am able to get the correct version strings.

What I like particularly is, that the dev version string contains the commit hash and is thus unique across multiple branches.

My workflow now looks like this:

  • create feature or fix branch
  • commit, (push, ) publish
  • merge PR to develop-branch

As soon as I am on my feature-branch I am able to run python -m build which generated a new _version.py with the correct version string accordingly to the latest git tag found. If I add new commits, it is fine, as the devN part of the version string changes due to the commit hash. I would even be able to run a python -m twine upload dist/* now. My package is build with correct version, so I simply publish it. This works perfectly fine localy and on CI for both fix and feature branches alike.

The problem that I am facing now, is, that I need a slightly different behavior for my merged PullRequests As soon as I merge, e.g. 0.0.1.dev####, I want to run my Jenkins job not on the feature-branch anymore, but instead on develop-branch. And the important part now is, I want to

  • get develop-branch (done by CI)
  • update version string to same as on branch but without devN, so: 0.0.1
  • build and publish

In fact, setuptools_scm is changing the version to 0.0.2.dev### now, and I would like to have 0.0.1. I was tinkering a bit with creating git tags before running setuptools_scm or build, but I was not able to get the correct version string to put into the tag. At this point I am struggling now.

Is anyone aware of a solution to tackle my issue with having?:

  • minor increment on feature-branches + add .devN
  • patch/micro increment on fix-branches + add .devN
  • no increment on develop-branch and version string only containing major.minor.patch of merged branch
Matthias
  • 1,200
  • 2
  • 13
  • 33

1 Answers1

1

TLDR: turning off to write the version number to a file every time setuptools_scm runs could maybe solve your problem, alternatively add the version file to .gitignore.

Explanation:

I also just started using setuptools_scm, so I am not very confident in using it yet.

But, as far as I understand the logic to derive the version number is incremented according to the state of your repository (the detailed logic is documented here: https://github.com/pypa/setuptools_scm/#default-versioning-scheme).

When I am not mistaken, the tool now does exactly what it is expected to: it does NOT set a version name only derived from the tag, but also adds a devSomething because the tag you've set is not referencing the most current commit on the develop branch head in your case.

Also I had the problem that when letting setuptools_scm generate a version and also configuring it to write it to a file, this would lead to another state since the last commit, again generating a dev version number.

To get a "clean" (e.g. v0.0.1) version number I hat to do the tagging after merging (with merge commit) since the merge commit was also taken into account for the version numbering logic.

Still my setup is currently less complex than yours. Just feature and fix branches and just a main branch without develop. So fewer merge commits (I chose to do merge commits, so no linear history). Now after merging with commit I create a Tag manually and formulate its name myself.

And this also only works for me in case I opt-out for writing the version number into a file. This I have done by inserting the following into pyproject.toml:

[tool.setuptools_scm]
# intentionally empty/commented out
# write_to option leads to an unclean workspace during build
# which again is leading setuptools_scm to interpret this during build and producing wheels with unclean version numbers
# write_to = "version.txt"

Since setuptools_scm runs during build, a new version file is also generated, which pollutes your worktree. Since your worktree will never be clean this way, you always get a dev version number. To still have a version file and to let it ignore during build, add the file to your .gitignore.

My approach is not perfect, some manual steps, but for now it works for me. Certainly not 100% applicable in your CI scenario, but maybe you could change the order of doing merges and tags. I hope this helps somehow.

Pascal
  • 812
  • 7
  • 19
  • yes I also thought about tagging after the merge. I guess this is the way the setuptools_scm guys thought of as well. feels like at least. But if I place the tag myself I don't really get the sense of automating the versioning. – Matthias Feb 10 '23 at 13:56
  • 1
    @Matthias true, but the point here is not automating, I think. The point is a tradeoff of being very precise with the versioning when using `setuptools_scm`. It tells you the current version, when you installed the tagged version or checked it out. It tells you how far away you are from the last tag(in terms of commits or hashes). E.g. for identifying potential version dependent bugs. This is at least how I use it. When you want to automate the versioning, you can use e.g. poetry (https://py-pkgs.org/07-releasing-versioning.html#version-bumping) in your pipeline. thx for upvote if it helped. – Pascal Feb 15 '23 at 11:15