Inconsistency between `setuptools_scm.get_version()` and `write_to` results

[Abhinav Singh]

We use the following to automatically write a version file upon pip install -e . which then gets shipped within the container.

[tool.setuptools_scm]
write_to = "path/to/somewhere/_scm_version.py"

During Python repo's build process, we collect static and push to a cloud storage. Path for upload is generated using setuptools_scm.get_version() by the build process. During runtime, server is able to appropriately point to storage based upon version written in _scm_version.py. This has worked for 99% of the scenarios for us till now, but we are starting to experience inconsistencies between the two results. Below is an example:

• 1.0.1rc36.dev1137%2Bgef403e8 from _scm_version.py
• 1.0.1rc36.dev1137%2Bgef403e86 from setuptools_scm.get_version()

Notice 7 vs 8 character hash, which leads to service unable to load necessary static. Per https://git-scm.com/docs/git-describe#_examples I understand that "The length of the abbreviation scales as the repository grows, using the approximate number of objects in the repository and a bit of math around the birthday paradox, and defaults to a minimum of 7", but why this inconsistency within setuptools_scm.

As a workaround:

• Any recommendation on how can we ensure consistency between the two outputs?
• We might just remove +g.... from our static path annotations. It is just good to have a commit hash directly in the url for debugging purposes.

[Ronny Pfannschmidt]

you could request the full nodeid instead of a abbreviation in a custom command

ts not lear to me whats the issue

i suspect there may be inonsistenc in the way setuptools_scm abbreviates (i do recall we have a fewl ....[:7] there