3

I am trying to understand what version a github package has. I am building it locally. In the release process, I find this:

VERSION=$(python setup.py --version)

In my repo, whenever I run this I get:

» python setup.py --version 1.0.9.dev29

But I have no clue where this is coming from. The version 1.0.9.dev29 is neither in the setup.cfg, nor in a separate VERSION file. There is no version file or similar in the repo. I do not understand how setuptools is able to derive this version id. The documentation does not give any hints.

How does the python setup.py --version command work?

Improve this question
6
  • 1
    Have you looked at setup.py yet? :-) Commented May 2, 2017 at 6:55
  • @MartijnPieters: yes, and it has nothing related to the version (I had to reorg the links, they were wrong). I do think that --version gives me the version of the package, not of setuptools. Commented May 2, 2017 at 6:57
  • 1
    It looks as though the package in question is using pbr; the answer to where the version comes from is probably in the pbr documentation somewhere. In particular: "In both cases version strings are inferred from git." So it looks as though the version is based on the most recent tagged git revision. Commented May 2, 2017 at 7:05
  • Indeed, I got it wrong and --version produces the version field in the metadata. This specific project uses a third-party project called pbr to set that up. Commented May 2, 2017 at 7:09
  • @MarkDickinson makes sense, can accept as answer. I do not know how you did infer that it was using pbr Commented May 2, 2017 at 7:09

2 Answers 2

Reset to default
3

setup.py --version lists the version of a package taken from the metadata. Your specific project uses the pbr package to handle metadata:

setup_requires=['pbr>=1.9', 'setuptools>=17.1', 'pytest-runner'],

pbr (Python Build Reasonableness) sets a version at package build time by looking at the current git history, see the Version section of the pbr documentation:

Versions can be managed two ways - postversioning and preversioning. Postversioning is the default, and preversioning is enabled by setting version in the setup.cfg metadata section. In both cases version strings are inferred from git.

If the currently checked out revision is tagged, that tag is used as the version.

So when the developer runs setup.py to build a distribution, at that time pbr looks at the git repository metadata and extracts a version number, and includes that in distributions that are built; the tar.gz source tarball includes a PKG-INFO file with the version.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

Per the accepted answer, the info is coming from your git repo, based on tags, using the pbr extension.

What's not included is how the actual string was determined. pbr uses an algorithm that is specified in the pbr documentation based on the latest tags that were created in the repo (I'm assuming searching the currently checked out branch, but not sure).

The 1.0.9.dev29 string likely means you have a 1.0.9 tag in the repo, with 29 commits that do not have a tag. By default, pbr will add a .devN postfix to a new commit without a tag, that increments with each new untagged commit.

If you add a 1.0.10 tag to the latest commit, that will be the new version, but if you add another commit without a tag, it will be 1.0.9.dev30.

See here for More info on the Semantic Versioning used by pbr

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.