- like a rocketeer, but for versions!
- https://github.com/warner/python-versioneer
- Brian Warner
- License: Public Domain
- Compatible With: python2.6, 2.7, 3.2, 3.3, 3.4, and pypy
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.
pip install versioneer
to somewhere to your $PATH- run
versioneer-installer
in your source tree: this installsversioneer.py
- follow the instructions below (also in the
versioneer.py
docstring)
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 "setup.py 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
_version.py
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 'setup.py sdist' tarball
Versioneer works by adding a special _version.py
file into your source
tree, where your __init__.py
can import it. This _version.py
knows how to
dynamically ask the VCS tool for version information at import time. However,
when you use "setup.py build" or "setup.py sdist", _version.py
in the new
copy is replaced by a small static file that contains just the generated
version data.
_version.py
also contains $Revision$
markers, and the installation
process marks _version.py
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.
First, decide on values for the following configuration variables:
-
VCS
: the version control system you use. Currently accepts "git". -
versionfile_source
:A project-relative pathname into which the generated version strings should be written. This is usually a
_version.py
next to your project's main__init__.py
file, so it can be imported at runtime. If your project usessrc/myproject/__init__.py
, this should besrc/myproject/_version.py
. This file should be checked in to your VCS as usual: the copy created below bysetup.py 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
_version.py
), since "setup.py sdist" -based trees still need somewhere to record the pre-calculated version strings. Anywhere in the source tree should do. If there is a__init__.py
next to your_version.py
, thesetup.py 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 setup.py uses 'package_dir='. If you havepackage_dir={'myproject': 'src/myproject'}
, then you will probably haveversionfile_build='myproject/_version.py'
andversionfile_source='src/myproject/_version.py'
.If this is set to None, then
setup.py build
will not attempt to rewrite any_version.py
in the built tree. If your project does not have any libraries (e.g. if it only builds a script), then you should useversionfile_build = None
and overridedistutils.command.build_scripts
to explicitly insert a copy ofversioneer.get_version()
into your generated script. -
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.
-
parentdir_prefix
:a 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-'.
This tool provides one script, named versioneer-installer
. That script does
one thing: write a copy of versioneer.py
into the current directory.
To versioneer-enable your project:
-
1: Run
versioneer-installer
to copyversioneer.py
into the top of your source tree. -
2: add the following lines to the top of your
setup.py
, with the configuration values you decided earlier:import versioneer versioneer.VCS = 'git' versioneer.versionfile_source = 'src/myproject/_version.py' versioneer.versionfile_build = 'myproject/_version.py' versioneer.tag_prefix = '' # tags are like 1.2.0 versioneer.parentdir_prefix = 'myproject-' # dirname like 'myproject-1.2.0'
-
3: add the following arguments to the setup() call in your setup.py:
version=versioneer.get_version(), cmdclass=versioneer.get_cmdclass(),
-
4: now run
setup.py versioneer
, which will create_version.py
, and will modify your__init__.py
(if one exists next to_version.py
) to define__version__
(by calling a function from_version.py
). It will also modify yourMANIFEST.in
to include bothversioneer.py
and the generated_version.py
in sdist tarballs. -
5: commit these changes to your VCS. To make sure you won't forget,
setup.py versioneer
will mark everything it touched for addition.
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 setup.py 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
Currently, all version strings must be based upon a tag. Versioneer will report "unknown" until your tree has at least one tag in its history. This restriction will be fixed eventually (see issue #12).
Code which uses Versioneer can learn about its version string at runtime by
importing _version
from your main __init__.py
file and running the
get_versions()
function. From the "outside" (e.g. in setup.py
), you can
import the top-level versioneer.py
and run get_versions()
.
Both functions return a dictionary with different keys for different flavors of the version string:
-
['version']
: condensed tag+distance+shortid+dirty identifier. For git, this uses the output ofgit describe --tags --dirty --always
but strips the tag_prefix. 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". -
['full']
: detailed revision identifier. For Git, this is the full SHA1 commit id, followed by "-dirty" if the tree contains uncommitted changes, e.g. "1076c978a8d3cfc70f408fe5974aa6c092c949ac-dirty".
Some variants are more useful than others. Including full
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.
In the future, this will also include a
PEP-0440 -compatible flavor
(e.g. 1.2.post0.dev123
). This loses a lot of information (and has no room
for a hash-based revision id), but is safe to use in a setup.py
"version=
" argument. It also enables tools like pip to compare version
strings and evaluate compatibility constraint declarations.
The setup.py versioneer
command adds the following text to your
__init__.py
to place a basic version in YOURPROJECT.__version__
:
from ._version import get_versions
__version__ = get_versions()['version']
del get_versions
To upgrade your project to a new release of Versioneer, do the following:
- install the new Versioneer (
pip install -U versioneer
or equivalent) - re-run
versioneer-installer
in your source tree to replace your copy ofversioneer.py
- edit
setup.py
, if necessary, to include any new configuration settings indicated by the release notes - re-run
setup.py versioneer
to replaceSRC/_version.py
- commit any changed files
You must add a versioneer.VCS = "git"
to your setup.py
before re-running
setup.py versioneer
. This will enable the use of additional version-control
systems (SVN, etc) in the future.
Nothing special.
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 versioneer.py
script is assembled from these
components by running make-versioneer.py . In the future, make-versioneer.py
will take a VCS name as an argument, and will construct a version of
versioneer.py
that is specific to the given VCS. It might also take the
configuration arguments that are currently provided manually during
installation by editing setup.py . Alternatively, it might go the other
direction and include code from all supported VCS systems, reducing the
number of intermediate scripts.
To make Versioneer easier to embed, all its code is hereby released into the
public domain. The _version.py
that it creates is also in the public
domain.