Add version info to druid package and use it for CLI version output

[simonvanderveldt]

This uses https://pypi.org/project/setuptools-scm/ + https://pypi.org/project/setuptools-scm-git-archive/ which is a bit "magic", but from my testing this is the only way to get the version automatically with the following criteria:

• The only action necessary to update the version is git tag
• Release archives from GitHub should work and show the correct version
• During development it should be clear that a "development version" is being used. Ideally the shorthash + something like dev should be shown

Some output examples:

$ druid --version          
druid, version 0.1.2.dev17+g971de94
$ git tag -a 0.1.3 -m "thisisatest"
$ druid --version
druid, version 0.1.3
$ echo "foo" > test.txt
$ git add test.txt
$ druid --version
druid, version 0.1.4.dev0+g07eb4c8.d20191021

And when making a release archive (which is what GitHub does):

$ git tag -a 0.1.3 -m "thisisatest" 
$ git archive add-version-info | gzip > test.tgz
$ tar -axf test.tgz .git_archival.txt -O       
ref-names: HEAD -> add-version-info, tag: 0.1.3, origin/add-version-info

And when installing from this archive

$ pip install test.tgz
...
$ druid --version
druid, version 0.1.3

@csboling what do you think?

Fixes #29

[simonvanderveldt]

We need to have these installed at runtime as well, otherwise the detection isn't possible.
Not super happy about that but if you want runtime detection there isn't really another option. We can of course discuss if we want/need runtime detection, but personally I quiet like it if we ask someone for some info for a bug that we know that something might or might not have been changed,

[simonvanderveldt]

This is some git "magic" that processes the file on the left using the attribute on the right.
export-subst basically substitutes some placeholders, see https://git-scm.com/docs/gitattributes#_creating_an_archive for more details.

The result is something like

ref-names: HEAD -> add-version-info, tag: 0.1.3, origin/add-version-info

[trentgill]

This looks good to me, and I don't mind the extra packages now that we're using an automated setup with pip. I can't really comment on the implementation, but it's at least terse and reads cleanly to the uninitiated (read: myself).

Perhaps you could add a section to the readme which describes the necessary steps to make a new release? I know it's going to be automated at some point, but would be good to document the current situation.

[simonvanderveldt]

Perhaps you could add a section to the readme which describes the necessary steps to make a new release? I know it's going to be automated at some point, but would be good to document the current situation.

Good point! I'll add that tomorrow.

[trentgill]

@simonvanderveldt lmk what I can do to test this out and then let's check it in!

[simonvanderveldt]

@trentgill I don't expect it to behave differently on different OSes but if you could give it a spin on Mac OS and Windows that would be nice (although @csboling might do that as well)

[trentgill]

Tested all my systems and it seems to be working well! Merging now.

[csboling]

I just learned like seven new things about pip and git from trying to understand how this works, awesome. Very tidy solution!