setuptools_scm

setuptools_scm handles managing your python package versions in scm metadata instead of declaring them as the version argument or in a scm managed file.

It also handles file finders for the supported scm's.

https://travis-ci.org/pypa/setuptools_scm.svg?branch=master

Setup.py usage

To use setuptools_scm just modify your project's setup.py file like this:

Add 'setuptools_scm' to the setup_requires parameter

Add the use_scm_version parameter and set it to True

E.g.:

from setuptools import setup
setup(
    ...,
    use_scm_version=True,
    setup_requires=['setuptools_scm'],
    ...,
)

Arguments to get_version() (see below) may be passed as a dictionary to use_scm_version. For example:

from setuptools import setup
setup(
    ...,
    use_scm_version = {"root": "..", "relative_to": __file__},
    setup_requires=['setuptools_scm'],
    ...,
)

Access the version number in your package via pkg_resources

E.g. (PEP-0396):

from pkg_resources import get_distribution, DistributionNotFound
try:
    __version__ = get_distribution(__name__).version
except DistributionNotFound:
    # package is not installed
    pass

Programmatic usage

In order to use setuptools_scm from code that is one directory deeper than the project's root, you can use:

from setuptools_scm import get_version
version = get_version(root='..', relative_to=__file__)

See setup.py Usage above for how to use this within setup.py.

Usage from sphinx

It is discouraged to use setuptools_scm from sphinx itself, instead use pkg_resources after editable/real installation:

# contents of docs/conf.py
from pkg_resources import get_distribution
release = get_distribution('myproject').version
# for example take major/minor
version = '.'.join(release.split('.')[:2])

The underlying reason is, that services like readthedocs sometimes change the workingdirectory for good reasons and using the installed metadata prevents using needless volatile data there.

Notable Plugins

setuptools_scm_git_archive provides partial support for obtaining versions from git archives that belong to tagged versions. The only reason for not including it in setuptools-scm itself is git/github not supporting sufficient metadata for untagged/followup commits, which is preventing a consistent UX.

Default versioning scheme

In the standard configuration setuptools_scm takes a look at 3 things:

latest tag (with a version number)
the distance to this tag (e.g. number of revisions since latest tag)
workdir state (e.g. uncommitted changes since latest tag)

and uses roughly the following logic to render the version:

no distance and clean:: {tag}
distance and clean:: {next_version}.dev{distance}+{scm letter}{revision hash}
no distance and not clean:: {tag}+dYYYMMMDD
distance and not clean:: {next_version}.dev{distance}+{scm letter}{revision hash}.dYYYMMMDD

The next version is calculated by adding 1 to the last numeric component of the tag.

For git projects, the version relies on git describe, so you will see an additional g prepended to the {revision hash}.

Semantic Versioning (SemVer)

Due to the default behavior it's necessary to always include a patch version (the 3 in 1.2.3), or else the automatic guessing will increment the wrong part of the semver (e.g. tag 2.0 results in 2.1.devX instead of 2.0.1.devX). So please make sure to tag accordingly.

Note

Future versions of setuptools_scm will switch to SemVer by default hiding the the old behavior as an configurable option.

Builtin mechanisms for obtaining version numbers

the scm itself (git/hg)
.hg_archival files (mercurial archives)
PKG-INFO

Note

git archives are not supported due to git shortcomings

Configuration Parameters

In order to configure the way use_scm_version works you can provide a mapping with options instead of a boolean value.

The currently supported configuration keys are:

root:	Relative path to cwd, used for finding the scm root, defaults to `.`
version_scheme:	Configures how the local version number is constructed. Either an entrypoint name or a callable.
local_scheme:	Configures how the local component of the version is constructed. Either an entrypoint name or a callable.
write_to:	A path to a file that gets replaced with a file containing the current version. It is ideal for creating a version.py file within the package, typically used to avoid using pkg_resources.get_distribution (which adds some overhead). Warning Only files with `.py` and `.txt` extensions have builtin templates, for other file types it is necessary to provide `write_to_template`.
write_to_template:	A newstyle format string that is given the current version as the `version` keyword argument for formatting.
relative_to:	A file from which the root can be resolved. Typically called by a script or module that is not in the root of the repository to point setuptools_scm at the root of the repository by supplying `__file__`.
parse:	A function that will be used instead of the discovered SCM for parsing the version. Use with caution, this is a function for advanced use, and you should be familiar with the setuptools_scm internals to use it.

To use setuptools_scm in other Python code you can use the get_version function:

from setuptools_scm import get_version
my_version = get_version()

It optionally accepts the keys of the use_scm_version parameter as keyword arguments.

Environment Variables

SETUPTOOLS_SCM_PRETEND_VERSION:	when defined and not empty, its used as the primary source for the version number in which case it will be a unparsed string
SETUPTOOLS_SCM_DEBUG:	when defined and not empty, a lot of debug information will be printed as part of setuptools_scm operating

Extending setuptools_scm

setuptools_scm ships with a few setuptools entrypoints based hooks to extend its default capabilities.

Adding a new SCM

setuptools_scm provides 2 entrypoints for adding new SCMs

setuptools_scm.parse_scm

A function used to parse the metadata of the current workdir using the name of the control directory/file of your SCM as the entrypoint's name. E.g. for the built-in entrypoint for git the entrypoint is named .git and references 'setuptools_scm.git:parse'.

The return value MUST be a setuptools.version.ScmVersion instance created by the function setuptools_scm.version:meta.

setuptools_scm.files_command

Either a string containing a shell command that prints all SCM managed files in its current working directory or a callable, that given a pathname will return that list.

Also use then name of your SCM control directory as name of the entrypoint.

Version number construction

setuptools_scm.version_scheme

Configures how the version number is constructed given a setuptools.version.ScmVersion instance and should return a string representing the version.

Available implementations:

guess-next-dev:	automatically guesses the next development version (default)
post-release:	generates post release versions (adds `postN`)

setuptools_scm.local_scheme

Configures how the local part of a version is rendered given a setuptools.version.ScmVersion instance and should return a string representing the local version.

Available implementations:

node-and-date:	adds the node on dev versions and the date on dirty workdir (default)
node-and-timestamp:	like `node-and-date` but with a timestamp of the form `{:%Y%m%d%H%M%S}` instead
dirty-tag:	adds `+dirty` if the current workdir has changes

Importing in setup.py

To support usage in setup.py passing a callable into use_scm_version is supported.

Within that callable, setuptools_scm is available for import. The callable must return the configuration.

# content of setup.py
import setuptools

def myversion():
    from setuptools_scm.version import get_local_dirty_tag
    def clean_scheme(version):
        return get_local_dirty_tag(version) if version.dirty else '+clean'

    return {'local_scheme': clean_scheme}

setup(
    ...,
    use_scm_version=myversion,
    ...
)

Note on testing non-installed versions

While the general advice is to test against a installed version, some environments require a test prior to install,

$ python setup.py egg_info
$ PYTHONPATH=$PWD:$PWD/src pytest

Code of Conduct

Everyone interacting in the setuptools_scm project's codebases, issue trackers, chat rooms, and mailing lists is expected to follow the PyPA Code of Conduct.

jpiron/setuptools_scm