Inconsistency between `setuptools_scm.get_version()` and `write_to` results
abhinavsingh opened this issue · comments
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.
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