Don't strip local version suffix from tag when specified

[mjsir911]

Hi,

We're tracking an internal version forked/downstream from a public project using setuptools_scm and would like to integrate a local version identifier into the generated wheels.

This is currently being done with SETUPTOOLS_SCM_PRETEND_VERSION=0.23+tp.0 but it would be nice for setuptools to not strip the + suffix from the current commit's tag.

[martinpakosch]

Hey @mjsir911 @RonnyPfannschmidt

I stumbled today across the same problem while testing hatchling with hatch-vcs plugin, which in turn depends on setuptools_scm. :) At the end I was able to fix the "issue" of the local version identifier being stripped by setuptools_scm (v8.3.0) and I tested it directly with setuptools_scm - not via hatch-vcs!

The reason seems to be, that setuptools_scm uses a default tag_regex, that does not catch the "+whatever.0" tag (by intend to be PyPI compliant?) and instead tries to make a simplified match on "canonical versions" only. It does not use the reference Regex from Python.org. And even with a local_scheme set to e.g. node-and-date it gets stripped.

My solution was to implement the Python reference pattern for canonical (normalized!) versions and extend it with the needed (normalized!) pattern for local version identifiers. This has been wrapped in a version-capture group. This is how it looks like, configured on user-side in the pyproject.toml:

[tool.setuptools_scm]
# tag_regex:  [ prefixes     ]            [ canonical                                                                                                                  ][ local                      ][ git-commit           ]
tag_regex = "^([\\w-]+-)?[vV]?(?P<version>([1-9][0-9]*!)?(0|[1-9][0-9]*)(\\.(0|[1-9][0-9]*))*((a|b|rc)(0|[1-9][0-9]*))?(\\.post(0|[1-9][0-9]*))?(\\.dev(0|[1-9][0-9]*))?(\\+[a-z0-9]+(\\.[a-z0-9]+)*)?(\\-[0-9]+\\-[a-z0-9]+)?)$"

Output of a clean working-dir matching HEAD with a new tag:

$ git tag
poc-2.1.5+mytag

$ python -m setuptools_scm
2.1.5+mytag

Hope this helps. :)

[RonnyPfannschmidt]

I'll investigate adding this