versioneer module

The Versioneer - like a rocketeer, but for versions.

The Versioneer

( ]( * [![Build Status] ( ](

This is a tool for managing a recorded version number in distutils-based python projects. The goal is to remove the tedious and error-prone “update the embedded version string” step from your release process. Making a new release should be as easy as recording a new tag in your version-control system, and maybe making new tarballs.

## Quick Install

  • pip install versioneer to somewhere to your $PATH
  • add a [versioneer] section to your setup.cfg (see below)
  • run versioneer install in your source tree, commit the results

## Version Identifiers

Source trees come from a variety of places:

  • a version-control system checkout (mostly used by developers)
  • a nightly tarball, produced by build automation
  • a snapshot tarball, produced by a web-based VCS browser, like github’s “tarball from tag” feature
  • a release tarball, produced by “ sdist”, distributed through PyPI

Within each source tree, the version identifier (either a string or a number, this tool is format-agnostic) can come from a variety of places:

  • ask the VCS tool itself, e.g. “git describe” (for checkouts), which knows about recent “tags” and an absolute revision-id
  • the name of the directory into which the tarball was unpacked
  • an expanded VCS keyword ($Id$, etc)
  • a created by some earlier build step

For released software, the version identifier is closely related to a VCS tag. Some projects use tag names that include more than just the version string (e.g. “myproject-1.2” instead of just “1.2”), in which case the tool needs to strip the tag prefix to extract the version identifier. For unreleased software (between tags), the version identifier should provide enough information to help developers recreate the same tree, while also giving them an idea of roughly how old the tree is (after version 1.2, before version 1.3). Many VCS systems can report a description that captures this, for example git describe –tags –dirty –always reports things like “0.7-1-g574ab98-dirty” to indicate that the checkout is one revision past the 0.7 tag, has a unique revision id of “574ab98”, and is “dirty” (it has uncommitted changes.

The version identifier is used for multiple purposes:

  • to allow the module to self-identify its version: myproject.__version__
  • to choose a name and prefix for a ‘ sdist’ tarball

## Theory of Operation

Versioneer works by adding a special file into your source tree, where your can import it. This knows how to dynamically ask the VCS tool for version information at import time. also contains $Revision$ markers, and the installation process marks to have this marker rewritten with a tag name during the git archive command. As a result, generated tarballs will contain enough information to get the proper version.

To allow to compute a version too, a is added to the top level of your source tree, next to and the setup.cfg that configures it. This overrides several distutils/setuptools commands to compute the version when invoked, and changes build and sdist to replace with a small static file that contains just the generated version data.

## Installation

First, decide on values for the following configuration variables:

  • VCS: the version control system you use. Currently accepts “git”.

  • style: the style of version string to be produced. See “Styles” below for details. Defaults to “pep440”, which looks like TAG[+DISTANCE.gSHORTHASH[.dirty]].

  • versionfile_source:

    A project-relative pathname into which the generated version strings should be written. This is usually a next to your project’s main file, so it can be imported at runtime. If your project uses src/myproject/, this should be src/myproject/ This file should be checked in to your VCS as usual: the copy created below by setup_versioneer will include code that parses expanded VCS keywords in generated tarballs. The ‘build’ and ‘sdist’ commands will replace it with a copy that has just the calculated version string.

    This must be set even if your project does not have any modules (and will therefore never import, since “ sdist” -based trees still need somewhere to record the pre-calculated version strings. Anywhere in the source tree should do. If there is a next to your, the setup_versioneer command (described below) will append some __version__-setting assignments, if they aren’t already present.

  • versionfile_build:

    Like versionfile_source, but relative to the build directory instead of the source directory. These will differ when your uses ‘package_dir=’. If you have package_dir={‘myproject’: ‘src/myproject’}, then you will probably have versionfile_build=’myproject/’ and versionfile_source=’src/myproject/’.

    If this is set to None, then build will not attempt to rewrite any in the built tree. If your project does not have any libraries (e.g. if it only builds a script), then you should use versionfile_build = None. To actually use the computed version string, your will need to override distutils.command.build_scripts with a subclass that explicitly inserts a copy of versioneer.get_version() into your script file. See test/demoapp-script-only/ for an example.

  • tag_prefix:

    a string, like ‘PROJECTNAME-‘, which appears at the start of all VCS tags. If your tags look like ‘myproject-1.2.0’, then you should use tag_prefix=’myproject-‘. If you use unprefixed tags like ‘1.2.0’, this should be an empty string, using either tag_prefix= or tag_prefix=’‘.

  • parentdir_prefix:

    a optional string, frequently the same as tag_prefix, which appears at the start of all unpacked tarball filenames. If your tarball unpacks into ‘myproject-1.2.0’, this should be ‘myproject-‘. To disable this feature, just omit the field from your setup.cfg.

This tool provides one script, named versioneer. That script has one mode, “install”, which writes a copy of into the current directory and runs setup to finish the installation.

To versioneer-enable your project:

  • 1: Modify your setup.cfg, adding a section named [versioneer] and populating it with the configuration values you decided earlier (note that the option names are not case-sensitive):

    [versioneer] VCS = git style = pep440 versionfile_source = src/myproject/ versionfile_build = myproject/ tag_prefix = parentdir_prefix = myproject- ````

  • 2: Run versioneer install. This will do the following:

    • copy into the top of your source tree
    • create in the right place (versionfile_source)
    • modify your (if one exists next to to define __version__ (by calling a function from
    • modify your to include both and the generated in sdist tarballs

    versioneer install will complain about any problems it finds with your or setup.cfg. Run it multiple times until you have fixed all the problems.

  • 3: add a import versioneer to your, and add the following arguments to the setup() call:

    version=versioneer.get_version(), cmdclass=versioneer.get_cmdclass(),

  • 4: commit these changes to your VCS. To make sure you won’t forget, versioneer install will mark everything it touched for addition using git add. Don’t forget to add and setup.cfg too.

## Post-Installation Usage

Once established, all uses of your tree from a VCS checkout should get the current version string. All generated tarballs should include an embedded version string (so users who unpack them will not need a VCS tool installed).

If you distribute your project through PyPI, then the release process should boil down to two steps:

  • 1: git tag 1.0
  • 2: python register sdist upload

If you distribute it through github (i.e. users use github to generate tarballs with git archive), the process is:

  • 1: git tag 1.0
  • 2: git push; git push –tags

Versioneer will report “0+untagged.NUMCOMMITS.gHASH” until your tree has at least one tag in its history.

## Version-String Flavors

Code which uses Versioneer can learn about its version string at runtime by importing _version from your main file and running the get_versions() function. From the “outside” (e.g. in, you can import the top-level and run get_versions().

Both functions return a dictionary with different flavors of version information:

  • [‘version’]: A condensed version string, rendered using the selected style. This is the most commonly used value for the project’s version string. The default “pep440” style yields strings like 0.11, 0.11+2.g1076c97, or 0.11+2.g1076c97.dirty. See the “Styles” section below for alternative styles.
  • [‘full-revisionid’]: detailed revision identifier. For Git, this is the full SHA1 commit id, e.g. “1076c978a8d3cfc70f408fe5974aa6c092c949ac”.
  • [‘dirty’]: a boolean, True if the tree has uncommitted changes. Note that this is only accurate if run in a VCS checkout, otherwise it is likely to be False or None
  • [‘error’]: if the version string could not be computed, this will be set to a string describing the problem, otherwise it will be None. It may be useful to throw an exception in if this is set, to avoid e.g. creating tarballs with a version string of “unknown”.

Some variants are more useful than others. Including full-revisionid in a bug report should allow developers to reconstruct the exact code being tested (or indicate the presence of local changes that should be shared with the developers). version is suitable for display in an “about” box or a CLI –version output: it can be easily compared against release notes and lists of bugs fixed in various releases.

The installer adds the following text to your to place a basic version in YOURPROJECT.__version__:

from ._version import get_versions __version__ = get_versions()[‘version’] del get_versions

## Styles

The setup.cfg style= configuration controls how the VCS information is rendered into a version string.

The default style, “pep440”, produces a PEP440-compliant string, equal to the un-prefixed tag name for actual releases, and containing an additional “local version” section with more detail for in-between builds. For Git, this is TAG[+DISTANCE.gHEX[.dirty]] , using information from git describe –tags –dirty –always. For example “0.11+2.g1076c97.dirty” indicates that the tree is like the “1076c97” commit but has uncommitted changes (“.dirty”), and that this commit is two revisions (“+2”) beyond the “0.11” tag. For released software (exactly equal to a known tag), the identifier will only contain the stripped tag, e.g. “0.11”.

Other styles are available. See in the Versioneer source tree for descriptions.

## Debugging

Versioneer tries to avoid fatal errors: if something goes wrong, it will tend to return a version of “0+unknown”. To investigate the problem, run version, which will run the version-lookup code in a verbose mode, and will display the full contents of get_versions() (including the error string, which may help identify what went wrong).

## Updating Versioneer

To upgrade your project to a new release of Versioneer, do the following:

  • install the new Versioneer (pip install -U versioneer or equivalent)
  • edit setup.cfg, if necessary, to include any new configuration settings indicated by the release notes
  • re-run versioneer install in your source tree, to replace SRC/
  • commit any changed files

### Upgrading to 0.16

Nothing special.

### Upgrading to 0.15

Starting with this version, Versioneer is configured with a [versioneer] section in your setup.cfg file. Earlier versions required the to set attributes on the versioneer module immediately after import. The new version will refuse to run (raising an exception during import) until you have provided the necessary setup.cfg section.

In addition, the Versioneer package provides an executable named versioneer, and the installation process is driven by running versioneer install. In 0.14 and earlier, the executable was named versioneer-installer and was run without an argument.

### Upgrading to 0.14

0.14 changes the format of the version string. 0.13 and earlier used hyphen-separated strings like “0.11-2-g1076c97-dirty”. 0.14 and beyond use a plus-separated “local version” section strings, with dot-separated components, like “0.11+2.g1076c97”. PEP440-strict tools did not like the old format, but should be ok with the new one.

### Upgrading from 0.11 to 0.12

Nothing special.

### Upgrading from 0.10 to 0.11

You must add a versioneer.VCS = “git” to your before re-running setup_versioneer. This will enable the use of additional version-control systems (SVN, etc) in the future.

## Future Directions

This tool is designed to make it easily extended to other version-control systems: all VCS-specific components are in separate directories like src/git/ . The top-level script is assembled from these components by running . In the future, will take a VCS name as an argument, and will construct a version of that is specific to the given VCS. It might also take the configuration arguments that are currently provided manually during installation by editing . Alternatively, it might go the other direction and include code from all supported VCS systems, reducing the number of intermediate scripts.

## License

To make Versioneer easier to embed, all its code is dedicated to the public domain. The that it creates is also in the public domain. Specifically, both are released under the Creative Commons “Public Domain Dedication” license (CC0-1.0), as described in .

exception versioneer.NotThisMethod

Bases: Exception

Exception raised if a method is not valid for the current scenario.

exception versioneer.VersioneerBadRootError

Bases: Exception

The project root directory is unknown or missing key files.

class versioneer.VersioneerConfig

Bases: object

Container for Versioneer configuration parameters.


Main VCS-independent setup function for installing Versioneer.

versioneer.do_vcs_install(manifest_in, versionfile_source, ipy)

Git-specific installation logic for Versioneer.

For Git, this means creating/changing .gitattributes to mark for export-time keyword substitution.


Get the custom setuptools/distutils subclasses used by Versioneer.


Read the project setup.cfg file to determine Versioneer config.


Get the project root directory.

We require that all commands are run from the project root, i.e. the directory that contains, setup.cfg, and .


Get the short version string for this project.


Get the project version from whatever source is available.

Returns dict with two keys: ‘version’ and ‘full’.


Extract version information from the given file.

versioneer.git_pieces_from_vcs(tag_prefix, root, verbose, run_command=<function run_command>)

Get version from ‘git describe’ in the root of the source tree.

This only gets called if the git-archive ‘subst’ keywords were not expanded, and hasn’t already been rewritten with a short version string, meaning we’re inside a checked out source tree.

versioneer.git_versions_from_keywords(keywords, tag_prefix, verbose)

Get version information from git keywords.


Return a + if we don’t already have one, else return a .

versioneer.register_vcs_handler(vcs, method)

Decorator to mark a method as the handler for a particular VCS.

versioneer.render(pieces, style)

Render the given version pieces into the requested style.



Like ‘git describe –tags –dirty –always’.

Exceptions: 1: no tags. HEX[-dirty] (note: no ‘g’ prefix)



Like ‘git describe –tags –dirty –always -long’. The distance/hash is unconditional.

Exceptions: 1: no tags. HEX[-dirty] (note: no ‘g’ prefix)


Build up version string, with post-release “local version identifier”.

Our goal: TAG[+DISTANCE.gHEX[.dirty]] . Note that if you get a tagged build and then dirty it, you’ll get TAG+0.gHEX.dirty

Exceptions: 1: no tags. git_describe was just HEX. 0+untagged.DISTANCE.gHEX[.dirty]


TAG[.postDISTANCE[.dev0]] .

The “.dev0” means dirty.

Eexceptions: 1: no tags. 0.postDISTANCE[.dev0]


TAG[.postDISTANCE[.dev0]+gHEX] .

The “.dev0” means dirty. Note that .dev0 sorts backwards (a dirty tree will appear “older” than the corresponding clean one), but you shouldn’t be releasing software with -dirty anyways.

Exceptions: 1: no tags. 0.postDISTANCE[.dev0]


TAG[.post.devDISTANCE] – No -dirty.

Exceptions: 1: no tags.

versioneer.run_command(commands, args, cwd=None, verbose=False, hide_stderr=False)

Call the given command(s).


Validate the contents of against Versioneer’s expectations.


Try to determine the version from if present.

versioneer.versions_from_parentdir(parentdir_prefix, root, verbose)

Try to determine the version from the parent directory name.

Source tarballs conventionally unpack into a directory that includes both the project name and a version string.

versioneer.write_to_version_file(filename, versions)

Write the given version number to the given file.