Use setuptools_scm for version number

[kotfu]

For issue #470, remove hard coded version numbers. Instead use setuptools_scm, which derives the version number from git tags.

setuptools_scm has a couple of drawbacks:

• you can't set the version number in any other way than by a git tag. If you want to increment the version number without tagging, you are out of luck.
• setuptools_scm is opinionated. If you follow semantic versioning, you must tag minor releases with the a patch level of '0', i.e. '2.0.0', not '2.0'
• if HEAD is not pointing at a tag, you get a long version number, i.e. 0.9.4.dev73+g4da2d37.d20180729. This is only visible to developers (because only developers should be running untagged versions of cmd2), but can be modified if we really want to change it.

The good news is that this PR takes away much of the pain of version increments.

[codecov]

Codecov Report

Merging #481 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #481      +/-   ##
==========================================
- Coverage   90.96%   90.96%   -0.01%     
==========================================
  Files          11       11              
  Lines        2868     2867       -1     
==========================================
- Hits         2609     2608       -1     
  Misses        259      259

Impacted Files	Coverage Δ
cmd2/cmd2.py	91.66% <ø> (-0.01%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2cfeac8...2cc07ec. Read the comment docs.

[kotfu]

This PR is currently failing on the VSTS build. I think it might be a problem with the build configuration. The test that is failing does:

assert cmd2.__version__

The only way that __version__ can generate an AttributeError (which is what is happening) is if the cmd2 package is not installed. I think that on the VSTS build, it's testing the source code in place, not installing the cmd2 package and testing the installed package.

[tleonhardt]

@kotfu I configured the VSTS macOS build to simply use pytest directly, so yeah it is just testing the code in place. My bad.

In the long run I’m going to switch the VSTS build to be Yaml based so the configuration is in our GitHub repo, but that feature is in preview so I didn’t want to rely on it yet.

In the meantime, see if you can create a free account at visualstudio.com and send me an email with your account name and I’ll add you as an admin to the cmd2 project there so you can tweak the build configuration. Alternatively just tell me what you think the best way to fix it is and I’ll change it. But it would probably be good for you to have access as well.

[tleonhardt]

So this is finally going to make me abandon my PYTHONPATH hack way of doing cmd2 development and switch to the pip way instead using:

$ cd ~/src/cmd2
$ pip install -e .

But that is probably a good thing ...

[tleonhardt]

@kotfu I modified the VSTS build so that it first uses pip to install cmd2 via:

$ pip install -e .

You should have gotten an email invite to join that VSTS account/project.

The VSTS macOS build capability is in somewhat of a preview state. A little down the road we will switch to using a YAML file to define the build to make it obvious what is going on and we will probably test on a couple versions of Python on macOS instead of just one. But I figured some automated build on macOS is better than no automated build on macOS ...