Pypi release

[steven-murray]

This PR gets hera_pspec for a PyPI release, by doing the following:

• It moves setup configuration to setup.cfg instead of setup.py. One potential problem here is that the old setup.py included the pipelines/ in the data. I'm not sure exactly how to make that happen in the setup.cfg format. It might be happening already, but I'm not sure. Someone should check that this is working as intended.
• Changed versioning to use setuptools_scm. This removes the hardcoded VERSION file, and also the version.py file which got the git info. Instead, this is all handled by setuptools_scm (in line with packages like pyuvdata). This means that versioning is set by making git tags.
• I updated the history_string function to use the new way of doing versioning (though this function doesn't actually seem to be used anywhere).

[acliu]

Quick thing...looks like some hidden files got committed by accident? In a .vscode directory, so I assume you must use vscode on your local machine.

[steven-murray]

Ah dang.

[steven-murray]

@acliu OK I removed those files.

[nkern]

the removal of version.py will probably break backwards compat, just fyi b/c our pipeline uses version to automatically print out the git / version info when we perform an analysis step in our pipeline. the easy thing to do is to keep version.py but just have it call utils.history_string() but still eliminate versioning from it and let scm handle it.

I know there are benefits to moving to setuptools_SCM, but tbh I never really got totally comfortable with it (maybe this will force me to). Can you give a brief explanation here for how we can easily duplicate what hera_pspec.version.print_version_info() is doing (from within a python interpreter)?

thanks ! :)

[steven-murray]

@nkern thanks for the heads up. I'm ok with adding the version.py back in just to have the call to utils.history_string -- hera_cal had a similar issue (@jsdillon opted to rip off the bandaid and just force updating all the notebooks that use this). I could also add a warning into the function in version.py with some kind of deprecation period, if you prefer.

So, with setuptools_scm the version is exclusively based on the git tag (so there's no file you need to update with the version in it). Other than reducing redundancy in terms of defining the version, it has the advantage that exact git info is folded into the version string itself as necessary. So, to get the version (in an interpreter) you'd just do from hera_pspec import __version__; print(__version__).

When your installed library is exactly on a commit that has an associated version tag, this will simply print eg. "v1.2.3". However, if you've made three commits since that v1.2.3 tag, it will print eg. "v.1.2.4.dev3+HASH". Since it includes the hash, you can always get back to the exact commit that produced it (similar to your print_version_info). Obviously if no hash is printed, you can simply go to the exact tag, which is just as good.

Is that a comprehensive-enough explanation?

[nkern]

hi @steven-murray that makes sense, thanks for the explanation! I hope it also helps us in the future if we need a refresher on this. this looks good to me otherwise!