get versions using metadata

[chrisjbillington]

In setup.py, use setuptools_scm to set the project version from git tags. If not on a tagged release, it will create a development version number in a format like:

2.15.1.dev34+g96c8c11.d20200430

Extend labscript_utils.versions.get_version() to first look for git repository metadata to determine the version of a package, in the case that it is being imported from a git repository.

Do not hard-code __version__ - instead determine own version using a call to get_version().

This means that for a git repository, the single source of truth for the version is the repository metadata. For an installed package, the single source of truth is the installation metadata. So long as packages use the default version format for setuptools_scm, the version from a git repo and then the subsequent installed package should be identical.

Other labscript suite packages may drop their manual version strings and set use_scm_version=True in their setup.py, and may replace their hard-coded __version__ attributes with the following in their __init__.py:

from pathlib import Path

from labscript_utils.versions import get_version, NoVersionInfo
__version__ = get_version(__name__, import_path=Path(__file__).parent.parent)
if __version__ is NoVersionInfo:
    __version__ = None

[chrisjbillington]

If people are happy or if nobody comments, I'll merge this and modify all the other packages to use it similarly.

[rpanderson]

This introduced breaking changes:

>>> import labscript_utils
>>> labscript_utils.__version__
'2.15.1.dev34+g6f29c66'
>>> labscript_utils.check_version('zprocess', '2.18.0', '3.0.0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\users\rpanderson\labscript-dev\labscript-utils\labscript_utils\versions.py", line 213, in check_version
    version = get_version(module_name, project_name)
  File "c:\users\rpanderson\labscript-dev\labscript-utils\labscript_utils\versions.py", line 176, in get_version
    version = setuptools_scm.get_version(import_path)
  File "C:\Users\rpanderson\labscript-dev\.venv\lib\site-packages\setuptools_scm\__init__.py", line 143, in get_version
    return _get_version(config)
  File "C:\Users\rpanderson\labscript-dev\.venv\lib\site-packages\setuptools_scm\__init__.py", line 147, in _get_version
    parsed_version = _do_parse(config)
  File "C:\Users\rpanderson\labscript-dev\.venv\lib\site-packages\setuptools_scm\__init__.py", line 110, in _do_parse
    raise LookupError(
LookupError: setuptools-scm was unable to detect version for 'C:\\Users\\rpanderson\\labscript-dev\\.venv\\lib\\site-packages'.
>>> import zprocess
>>> zprocess.__version__
'2.18.1'

Previously, this returned:

>>> import labscript_utils
>>> labscript_utils.__version__
'2.16.0.dev3'
>>> labscript_utils.check_version('zprocess', '2.18.0', '3.0.0')
>>> import zprocess
>>> zprocess.__version__
'2.18.1'

[rpanderson]

This is not remedied by upgrading to zprocess==2.19.0.

[chrisjbillington]

Thanks. I thought setuptools_scm returned None when the package was not a git repo. Apparently it is erroring in this case...will investigate, perhaps should check for the existence of a .git directory before calling setuptools_scm.check_version()

[chrisjbillington]

Should be fixed in eb0c05bfcc374c3d7b33fa3bda903c69d64979f3. Just catching the exception as indicative that it's not a git repo or PyPI tarball and moving on to trying metadata.

[chrisjbillington]

As for the labscript_utils version going down, that's to be expected - the previous hard-coded string was based on assuming what the next version number would be whereas setuptools_scm doesn't know that and is using the previous tag.

Will be remedied when we next tag a release.

[rpanderson]

Should be fixed in eb0c05b.

I cannot launch blacs, runmanager or runviewer with this, The error is the same in all cases, and arises when labscript_utils.check_version('labscript_utils', '2.13.2', '3') is called from each program's __init__.py. Here's an example traceback.

This command runs fine independently, and lyse launches okay.

[rpanderson]

This is not resolved by using the unmerged chrisjbillington/single-truth-version branches of each of blacs, runmanager, or runviewer.

[chrisjbillington]

I'll investigate. It might be because you're running from within a directory with the project repos all called by the same name as the modules, which might make import machinery confused (for me I've suffixed .git on the end of all of them because I suspected it might be an issue so that could explain it).

Looks like maybe I can fix just by converting a path to an absolute path: '' in sys.path is supposed to mean 'current directory', so I wonder if something is choking on that.

[rpanderson]

It might be because you're running from within a directory with the project repos all called by the same name as the modules

The same thing occurs with top-level directories that are either hyphenated or suffixed with .git.

[chrisjbillington]

Does adding a call to os.path.abspath here change anything?

# labscript_utils/versions.py line 177
return setuptools_scm.get_version(os.path.abspath(import_path))

[rpanderson]

It doesn't.

But I've discovered this issue is limited to ConEmu; I don't get the in a detached console or Windows Terminal, where I can launch all of the above if using the eb0c05b bugfix.