Derive developmental version build number from SCM through git describe

[tuukkamustonen]

Originally discussed in #77.

It seems like bumpversion relies on information coded in files (.bumpversion.cfg, setup.py) and cannot read information provided by SCM.

When building PEP440 developmental releases (maybe in CI), the build number (how many commits since the last release) should be obtained from SCM (git describe) and and appended to version (e.g. 1.2.3.dev0, 1.2.3.dev1, ...).

Something to take a look at is https://pypi.python.org/pypi/setuptools-version-command, which already does this (in a bit different way).

[tuukkamustonen]

Btw. the drawback with setuptools-version-command is that it needs to be installed before installing a source package (built with sdist) that uses it. I'm not sure, but I guess defining the library in setup_requires works in this case.

For binary packages, this requirement is lifted as version information gets hard-coded inside package (under *.dist-info/version.txt for wheels and EGG-INFO/version.txt for eggs).

[keimlink]

Could you please explain the feature with some pseudo shell code?

[tuukkamustonen]

Can you check https://github.com/j0057/setuptools-version-command/pull/3 ? Maybe that explains it better.

I just want dev0, dev1, dev2, etc. developmental build identifiers automatically, determined from git tag, without need to touch files in git.

[keimlink]

I'm asking for a more detailed proposal because I have several files containing the version that need to be updated on every release. If the tag is created at first and bumpversion is executed afterwards the tagged revision would contain the files with the old version. Such a setup can't be used to to package and upload a distribution because the version number of the distribution would not match the version number in the files (assuming that you build the distribution using the tagged revision).

[tuukkamustonen]

Ok, I will clarify the idea soon. Need to check couple of things first.

[tuukkamustonen]

@keimlink You're right, this idea of interpreting the actual version on the fly is problematic if you have version identifier in static files. Deciding the version identifier on-the-fly works ok when creating distribution packages, but if you want to have the version string in files in SCM (in documentation, maybe in __init__.py), we face the exact problem you describe.

While bumpversion is more flexible in some aspects, I'm going to use the setuptools-version-command for our needs and just close this. We don't record the version identifier anywhere, really, and it's simply interpreted during python setup.py bdist_wheel invocation. In code, we read the library version by:

pkg_resources.get_distribution("my-package").version

Out of curiosity, what are the "several files" you track the version in?

[peritus]

@tuukkamustonen Yes, bumpversion is not for every setup.

If you have a single point of truth (e.g. git's tags or a single file) for versions, then there's less need for it. Also, if you don't need to increment versions headless (say, e.g. in a contiuous integration environment by the press of a button), you can just do the computation in your head and do stuff manually.

Thanks for following up on this.