If a module installs softioc, and also uses VersionGit for versioning, the version number appears to be set to that of softioc when making a test release. This may also affect released modules.
Steps to reproduce (using Diamond tools):
dls-start-new-module.py -a python3 -n dls_example_module
cd dls_example_module/
pipenv install -d
pipenv install softioc
dls-py3 install-into-prefix
ls prefix/lib/python3.7/site-packages/
This will result in a module which shows the version to be 3.1, which is the latest release of softioc:
dls_example_module dls_example_module-3.1.dist-info
What I have found so far:
- It looks like _version_git in the your new module doesn't get called when
dls-py3 install-into-prefix is called.
- On a clean repository,
pipenv run python -m setup bdist_wheel will get the correct version (last tag + commit hash etc). If you run dls-py3 install-into-prefix first, the wheel will get stuck with the softioc version
- When running _version_git after install, it appears that GIT_REFS and GIT_SHA1 are set to the values from softioc
- This exists on (at least) versions 3.0, 3.0b2 and 3.1
If a module installs softioc, and also uses VersionGit for versioning, the version number appears to be set to that of softioc when making a test release. This may also affect released modules.
Steps to reproduce (using Diamond tools):
This will result in a module which shows the version to be 3.1, which is the latest release of softioc:
What I have found so far:
dls-py3 install-into-prefixis called.pipenv run python -m setup bdist_wheelwill get the correct version (last tag + commit hash etc). If you rundls-py3 install-into-prefixfirst, the wheel will get stuck with the softioc version