Use setuptools_scm for version

[taldcroft]

Inspired by the astropy proposal to use setuptools_scm for versioning, I gave this a spin for a worst-case package, namely the dual-install Ska.engarchive / cheta pair.

I like it! Basically this does what the original version.py wanted to do, but way better and using a clean package that is broadly accepted in the Python packaging community.

The key feature is use of the most recent git tag as the definition of version so that a hard-coded __version__ never appears in the repo. See versioning scheme for the details, but basically for a clean repo at the last tag you get that tag, but otherwise you always get handy "dev" info.

[taldcroft]

And I'm assuming for an installed version there will be no .git or anything related to a VCS, so no tries to call git and subsequent window flashing on Windows.

[taldcroft]

FYI, just tried installing the package and getting version and this fails. So something is not quite right yet.

[taldcroft]

And I'm assuming for an installed version there will be no .git or anything related to a VCS, so no tries to call git and subsequent window flashing on Windows.

4baa69d addresses both the previous comments, and in particular the installed package has no dependency on setuptools_scm so by definition it can't be calling git.

Now after installing to a test Ska3 and getting out of the source repo I get:

In [1]: import Ska.engarchive

In [2]: Ska.engarchive.__version__
Out[2]: '4.45.2.dev3+gf70fe12.d20190308'

In [3]: import cheta

In [4]: cheta.__version__
Out[4]: '4.45.2.dev3+gf70fe12.d20190308'

This is so nice because now you can install a dev version into a test Ska3 and actually see that you are getting a dev version of the package. No more pip install --ignore-installed . to cover up the fact that the "version" has not changed.

[taldcroft]

See sot/sparkles#107 for a simpler example.

@jeanconn @jzuhone - would this help, hurt, or have no impact on skare3 and our conda packaging?

[jzuhone]

I think this is fine with me--I've been using versioneer for non-CXC stuff lately, but I don't know how this compares to that.

[taldcroft]

Unfortunately this does not work with the current FOT Windows build process, which is relying on zip files from GitHub that don't have the required metadata for this to work. Need to put this aside for now.

[jeanconn]

Is https://pypi.org/project/setuptools-scm-git-archive/ helpful?

[taldcroft]

Interesting, worth checking.

[taldcroft]

It works! For testing I tagged this with 1.1.1 (there are no real releases 1.x). The change footprint is unfortunately bigger with those two new files, but not a showstopper. (I was thinking to factor out the version handling in <package>/__init__.py to a common function somewhere so that update becomes smaller and maintainable).

[taldcroft]

Actually, I fixed a typo in setup.py and tagged as 1.1.2. (Will clean these up later).

[taldcroft]

This installed on Windows 10 as well.

[jeanconn]

Great! I saw there was a note on the pypi page "Note that it only works for archives of tagged commits (because git currently lacks a format option equivalent to git describe --tags)." and I didn't know exactly what that meant as a caveat with regard to tagged things.

[taldcroft]

Yeah, just need to click on the tag and then get the zip file, and it seems to work.

[jeanconn]

Superseded by #187