Changes to use scm_setuptools

[javierggt]

Since I do not know how this affects backwards compatibility, I tried to leave the interface mostly unchanged. I think each package might have to be fixed to cleanup its interface.

In the case of kadi, the version is specified in various ways:

• __version__
• package_version
• __git_version__
• VERSION
• version

Right now all come from the same source.

I expect the changes in eng_archive to be similar

[taldcroft]

I suspect that much or all of the complexity in the current versioning output is really not used anywhere. E.g. https://github.com/search?q=org%3Asot+git_version&type=Code shows 9 places defining git_version but no configured code actually using it. The problem this was solving is being able to relate the version of imported code back to a specific commit or tag of the package. With setuptools_scm we can now do this reliably, without hacks like writing a GIT_VERSION file.

Which is a long way of saying that I propose just chopping the version.py file entirely and get rid of this historical cruft. So long as all testing passes, then we're good to go. Keep this PR open for a little while for reference, but basically I think we can say we are making a back-incompatible API change and if code needs fixing then we do it (fix and forward).

[taldcroft]

Have not tested but this all looks about right to me.

[jeanconn]

A nit, but probably also need an update in docs/conf.py .

[jeanconn]

And just searching for other uses of kadi.version it looks like there's one in find_attitude, so that probably needs a new issue

https://github.com/sot/find_attitude/blob/cefd1923ad2ddde2496f98943f6fb1e2b504866a/find_attitude/web/views.py#L5

if I'm understanding correctly that kadi.version will just not exist.

[javierggt]

Good catch. I will look for similar issues all over

[javierggt]

Looking for similar cases, I found a few, including:

• starcheck/src/starcheck.pl (it is in a big string that I suppose gets run... ??)
• starcheck/calc_ccd_temps.py

[jeanconn]

Yes, when you/we do starcheck we'll need to clean up some of its internal use of starcheck.version. And yes, that string in starcheck.pl is used asInline::Python block (though I think it is a separate starcheck issue to pull out more of the Python into files that can be appropriately flake8 checked and such instead of the string blocks).

[jeanconn]

I think this one is just superseded by #143