Released versions don't say they're the right version
alexgleith opened this issue · comments
A release build is pushed when we tag a branch, for example, 0.3.7.
If you run a docker image from this release and check the version, it'll be a version like '0.3.8.dev0+gb57bbac.d20201217', which is not right.
We need to fix it to say it's the right version.
When you say "check the version" do you mean the version of datacube-alchemist?
i.e. datacube_alchemist.__version__
Yeah, like that :-)
We fixed it in Datacube Explorer, I can't remember how https://github.com/opendatacube/datacube-explorer/blob/develop/.github/workflows/docker.yml
I think I know what's going on, then. It's not a docker issue, because you can replicate it from a regular pip install:
>>> pkg_resources.get_distribution('datacube_alchemist')
datacube-alchemist 0.3.8.dev2+g1219810 (repos\datacube-alchemist)
If this is indeed the version being problematic, it's automatically generated by setuptools_scm. This is an issue that has been documented in other projects when there are automatic processes like sphinx (or in this case Docker). Docker or another related process is dirtying the repo after the push hook starts but before the version is generated, and as a result setuptools_scm is generating a new version which represents the dirty tree: the release version plus one patch and the development node. That's why we get 0.3.8.dev... and so on. Explorer seems to have fixed this by writing the version to _version.py, which freezes the version into a module that can then be imported elsewhere. That might be all that's needed to fix it?
This would be the fix from datacube-explorer.
Perfect! Let's do it :-)
We can merge your fix and do a test release to see if it is effective.
What do you think about having a command line option to echo the version too, datacube-alchemist --version?
I'd really like that!
I'll submit a PR with both version fixes
Please send it to me, and refer to this issue in the description like "closes #67" and let's hope for the best :-)
Fixed in #70.