Merge ~harlowja/cloud-init:scm-version into cloud-init:master

[Joshua Harlow]

[Scott Moser (smoser)]

This would be runtime dependency, right?
i'd really rather not take that.

I'm not opposed to this and woudl like version information to follow *some* standard.

what i have now is just what comes out of git describe modified a bit.

see tools/make-tarball

# revname could be 0.7.5 or 0.7.5-NNN-gHASH
# turn that into 0.7.5 or 0.7.5+NNN.gHASH

that currently shows:
  0.7.6+1026-gef54bea

python -c 'from setuptools_scm import get_version; print(get_version())'
shows
  0.7.7.dev1023+ng72d6adc

is .dev1023+ngHASH
better in some way ?

[Joshua Harlow (harlowja)]

I guess the only thing that I can think about that makes using these tools useful is that they can provide a consistent way of getting that version (instead of yet another one-off way of getting it); pbr also has the nice ability to generate a debian version string and a redhat version string, which are quite useful when actually creating a package.

For example:

$ python setup.py rpm_version
running rpm_version
[pbr] Extracting rpm version
1.32.0.dev6

Not quite sure where the pbr output for deb_version is (thought it had this, ha).

That's usually the next question, ok, now that we have a version string crap here, well now I need a debian version of that string and I need a redhat version of that string.

[Joshua Harlow (harlowja)]

So https://review.openstack.org/#/c/350861 is the addition to pbr for the 'deb version' so this imho makes me lean towards using pbr vs this package, and using either over a custom hand rolled version calculation scheme. Because with a hand rolled scheme, I'll still need to be translating the output of that hand rolled scheme into a RPM compatible form, which means, at that point a automatic version derived from git isn't offering that much value (because a human still needs to translate it) :(

[Scott Moser (smoser)]

So In my head, here are the things that i need to cover:

a.) export of release tarball
b.) export of snapshot tarball
c.) upstream package build (./packages/brpm and ./package/bddeb)
    this basically does a export of a snapshot tarball and then build with local packaging.

d.) smoser upload to ubuntu of snapshot supporting build on 14.04+
    smoser does 'export of snapshot tarball'
    smoser adds a debian/changelog entry (which requires a debian sufficient version)

e.) i really would like for cloud-init runtime to show the "upstream version" in its greeting (the hole thing, not just 0.7.7).

In bzr, i would do http://bazaar.launchpad.net/~smoser/ubuntu/xenial/cloud-init/pkg/view/head:/debian/new-upstream-snapshot and it would handle it all.

The key things this all means i think are
1.) I don't want to require some new pip installed version of a package in order to build a tarball (i want to be able to do that on 14.04)
2.) there is an 'upstream' version that is basically then translated to debian and rpm versions.
3.) i don't want / can't have some new version of pbr installed in 14.04 on official build systems.
4.) i definitely can't pick up a runtime dependency to simply translate
    0.7.6-1023-g72d6adc to 0.7.6+1023-g72d6adc

Thoughts?

[Scott Moser (smoser)]

oh, just want to point out that yes, i also want the most standard package versioning i can get (although i think there are no standard package versions in reality, but pbr seems to have hopes of getting there at least).

[Scott Moser (smoser)]

the needed functionality is now in trunk via usage of tools/read-version.

Unmerged commits

cc78be5... by Joshua Harlow on 2016-08-01

Use 'setuptools_scm' for version string creation

This package, supported by the pypa community allows
for gathering of version information from git itself
so using it allows for dynamic version creation in a
hopefully stable manner, which can then be used by
package builders (and more).

a7a6ed2... by Joshua Harlow on 2016-08-01

Use 'setuptools_scm' to determine current version (from scm)

diff --git a/cloudinit/version.py b/cloudinit/version.py
index 3d1d1d2..4fc958c 100644
--- a/cloudinit/version.py
+++ b/cloudinit/version.py
@@ -16,12 +16,4 @@
 #    You should have received a copy of the GNU General Public License
 #    along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
-from distutils import version as vr
-
-
-def version():
-    return vr.StrictVersion("0.7.7")
-
-
-def version_string():
-    return str(version())
+from setuptools_scm import get_version as version_string
diff --git a/requirements.txt b/requirements.txt
index cc1dc05..b5a4ef2 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,4 +1,5 @@
 # Pypi requirements for cloud-init to work
+setuptools_scm
 
 # Used for untemplating any files or strings with parameters.
 jinja2
diff --git a/setup.py b/setup.py
index 0af576a..b07d0d2 100755
--- a/setup.py
+++ b/setup.py
@@ -209,6 +209,8 @@ setuptools.setup(
     data_files=data_files,
     install_requires=requirements,
     cmdclass=cmdclass,
+    use_scm_version=True,
+    setup_requires=['setuptools_scm'],
     entry_points={
         'console_scripts': [
             'cloud-init = cloudinit.cmd.main:main'