Package: setupext-gitversion
Wait… Why? What??PEP440codifies a version scheme for Python packages.  Thissetuptoolsextension will generateDevelopmental ReleaseandLocal Version Labelsegments that identify the revision that is being built.PEP440defines
the following format for Python package versions:version         = [epoch "!"] public-version ["+" local-version]
epoch           = digit+
public-version  = release-segment [pre-segment] [post-segment] [dev-segment]
local-version   = (letter | digit)+ ["." (letter|digit)+]
release-segment = digit+ ("." digit+)*
pre-segment     = "a" digit+ | "b" digit+ | "rc" digit+
post-segment    = ".post" digit+
dev-segment     = ".dev" digit+It also recommends that package indecies only acceptfinal releaseswhich
are defined as having a version that consists of only a release segment and
an optional epoch.  So why did I go through all of the trouble to create an
extension for managing versions that should not be submitted to a package
index?  If you develop Python packages that are used inside the walls of a
business, then you probably know exactly why – using a local Python Package
Index that holds non-public packages is commonplace.  It is also common to
stage pre-release packages and builds from a CI server in an internal index.
This is where this extension comes into play.  It provides a consistent way
to manage package versions throughout all stages of development.Let’s look at the state of this project as I am writing this document.  The
git history looks like the following:* 3fdc192 - (HEAD, origin/initial-implementation, initial-implementation)
###### 9 more commits here
* 7ca1fd2 - (origin/master, master)
*   87d944e - Merge pull request #1 from dave-shawley/reorg (6 days ago)
|\
| * 04d0cca - (origin/reorg, reorg)
| ###### 9 more commits here
|/
* bd7ad3c - (tag: 0.0.0) SYN (4 months ago)When I runsetup.py git_versionit sets the version to0.0.0.post1.dev11.
The0.0.0portion is the release segment that is passed to thesetupfunction insetup.py.   The extension finds that tag in the history and
counts the number of merges that have occurred since that tag – this value
becomes thepostversion segment.  In this case there has only been a single
merge.  Then it counts the number of commits since the last merge occurred –
this value becomes thedevelopmentversion segment.How?The easiest way to use this extension is to install it into your build
environment and then use it from the command line when you generate and upload
your distribution.pip installsetupext-gitversioninto your build environmentAdd the following lines to yoursetup.cfg:[git_version]version-file=LOCAL-VERSIONAdd the following line to yourMANIFEST.in:include LOCAL-VERSIONModify yoursetup.pyto append the contents ofLOCAL-VERSIONto yourversionkeyword:version_suffix=''try:withopen('LOCAL-VERSION')asf:version_suffix=f.readline().strip()exceptIOError:passsetup(# normal keywordsversion='1.2.3'+version_suffix,)Where1.2.3is the tag of the last release package.Addgit_versionto youruploador distribution generation
command.  You want to use something like the following:setup.py git_version sdist upload
setup.py git_version bdist_egg uploadAnd that’s it.  That will embed SCM information into your package when
your build a distribution.  It is also smart enough to generate an empty
suffix for a build from a tagged commit.Ok… Where?Sourcehttps://github.com/dave-shawley/setupext-gitversionStatushttps://travis-ci.org/dave-shawley/setupext-gitversionDownloadhttps://pypi.python.org/pypi/setupext-gitversionDocumentationhttp://setupext-gitversion.readthedocs.org/en/latestIssueshttps://github.com/dave-shawley/setupext-gitversion