Get version from git tags (through pbr)
I use pbr for packaging. It takes the version from git tags and applies that to setup.py
Now I also want to have the version available inside the package. For instance to have a __version__
attribute. Can I use the pbr
library for this?
There is another library: versioneer that also extracts the version from the git tags, but that would add an extra requirement. I would prefer to get this functionality from pbr
python versioning
add a comment |
I use pbr for packaging. It takes the version from git tags and applies that to setup.py
Now I also want to have the version available inside the package. For instance to have a __version__
attribute. Can I use the pbr
library for this?
There is another library: versioneer that also extracts the version from the git tags, but that would add an extra requirement. I would prefer to get this functionality from pbr
python versioning
Isn'tpbr
already an "extra requirement"?
– Bailey Parker
Jan 22 '18 at 14:25
It is a requirement, but it is one that I will use for packaging anyways. It gets a lot of its info from git, satisfying the DRY principle (authors, ChangeLog, etc). One of the things it does is generate a version for use in setup.py. Merely looking for a way to leverage that.
– Roy Prins
Jan 22 '18 at 15:14
add a comment |
I use pbr for packaging. It takes the version from git tags and applies that to setup.py
Now I also want to have the version available inside the package. For instance to have a __version__
attribute. Can I use the pbr
library for this?
There is another library: versioneer that also extracts the version from the git tags, but that would add an extra requirement. I would prefer to get this functionality from pbr
python versioning
I use pbr for packaging. It takes the version from git tags and applies that to setup.py
Now I also want to have the version available inside the package. For instance to have a __version__
attribute. Can I use the pbr
library for this?
There is another library: versioneer that also extracts the version from the git tags, but that would add an extra requirement. I would prefer to get this functionality from pbr
python versioning
python versioning
asked Jan 22 '18 at 14:23
Roy PrinsRoy Prins
901927
901927
Isn'tpbr
already an "extra requirement"?
– Bailey Parker
Jan 22 '18 at 14:25
It is a requirement, but it is one that I will use for packaging anyways. It gets a lot of its info from git, satisfying the DRY principle (authors, ChangeLog, etc). One of the things it does is generate a version for use in setup.py. Merely looking for a way to leverage that.
– Roy Prins
Jan 22 '18 at 15:14
add a comment |
Isn'tpbr
already an "extra requirement"?
– Bailey Parker
Jan 22 '18 at 14:25
It is a requirement, but it is one that I will use for packaging anyways. It gets a lot of its info from git, satisfying the DRY principle (authors, ChangeLog, etc). One of the things it does is generate a version for use in setup.py. Merely looking for a way to leverage that.
– Roy Prins
Jan 22 '18 at 15:14
Isn't
pbr
already an "extra requirement"?– Bailey Parker
Jan 22 '18 at 14:25
Isn't
pbr
already an "extra requirement"?– Bailey Parker
Jan 22 '18 at 14:25
It is a requirement, but it is one that I will use for packaging anyways. It gets a lot of its info from git, satisfying the DRY principle (authors, ChangeLog, etc). One of the things it does is generate a version for use in setup.py. Merely looking for a way to leverage that.
– Roy Prins
Jan 22 '18 at 15:14
It is a requirement, but it is one that I will use for packaging anyways. It gets a lot of its info from git, satisfying the DRY principle (authors, ChangeLog, etc). One of the things it does is generate a version for use in setup.py. Merely looking for a way to leverage that.
– Roy Prins
Jan 22 '18 at 15:14
add a comment |
2 Answers
2
active
oldest
votes
Consider setuptools_scm, which pulls a version from a git or hg tag when available, or generates an appropriate dev release version (e.g., hgvs-1.2.5.dev6+hb5d989061852.d20181124
). The version is written into package metadata as with a hardcoded version. No non-standard runtime support is needed.
Although I've used setuptools_scm for many projects, I've not used PBR. I was curious and worked up this simple demo:
snafu$ head setup.py setup.cfg pbrversiontest/*.py
==> setup.py <==
from setuptools import setup
setup(
setup_requires=[
"pbr",
"setuptools_scm"
],
pbr=True,
use_scm_version=True,
)
==> setup.cfg <==
[metadata]
name = pbrversiontest
summary = test whether we can use pbr and setuptools_scm
[files]
packages =
pbrversiontest
==> pbrversiontest/__init__.py <==
# This is straight from setuptools_scm README
from pkg_resources import get_distribution, DistributionNotFound
try:
__version__ = get_distribution(__name__).version
except DistributionNotFound:
# package is not installed
pass
==> pbrversiontest/__main__.py <==
# this isn't required -- only for the demo
import pbrversiontest
print("version is " + pbrversiontest.__version__)
In the development directory, you might have a session like so:
snafu$ python3.6 -mvenv venv/3.6
snafu$ source venv/3.6/bin/activate
(3.6) snafu$ git tag 0.1.2
(3.6) snafu$ pip install -e .
(3.6) snafu$ python -m pbrversiontest
version is 0.1.2
(3.6) snafu$ pip install wheel
(3.6) snafu$ python setup.py bdist_wheel
...
creating 'dist/pbrversiontest-0.1.2-py3-none-any.whl' and adding 'build/bdist.linux-x86_64/wheel' to it
...
(3.6) snafu$ unzip -l dist/pbrversiontest-0.1.2-py3-none-any.whl
Archive: dist/pbrversiontest-0.1.2-py3-none-any.whl
Length Date Time Name
--------- ---------- ----- ----
192 2018-11-25 05:26 pbrversiontest/__init__.py
73 2018-11-25 05:46 pbrversiontest/__main__.py
33 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/AUTHORS
217 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/METADATA
92 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/WHEEL
47 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/pbr.json
15 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/top_level.txt
675 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/RECORD
--------- -------
1344 8 files
P.S. The advantage of a setup like this is that the scm becomes the sole/authoritative source for version tags. That makes it hard for code to misrepresent its version number (or prd/dev/rc status).
– Reece
Nov 28 '18 at 4:56
add a comment |
If you are fine with pbr
being a runtime dependency of your package, then you can use the VersionInfo
class from pbr.version
:
from pbr.version import VersionInfo
package_name='my_package'
info = VersionInfo(package_name)
print(info.version_string())
(See also How to load package version into __version__ variable if you are using pbr?)
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f48383737%2fget-version-from-git-tags-through-pbr%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Consider setuptools_scm, which pulls a version from a git or hg tag when available, or generates an appropriate dev release version (e.g., hgvs-1.2.5.dev6+hb5d989061852.d20181124
). The version is written into package metadata as with a hardcoded version. No non-standard runtime support is needed.
Although I've used setuptools_scm for many projects, I've not used PBR. I was curious and worked up this simple demo:
snafu$ head setup.py setup.cfg pbrversiontest/*.py
==> setup.py <==
from setuptools import setup
setup(
setup_requires=[
"pbr",
"setuptools_scm"
],
pbr=True,
use_scm_version=True,
)
==> setup.cfg <==
[metadata]
name = pbrversiontest
summary = test whether we can use pbr and setuptools_scm
[files]
packages =
pbrversiontest
==> pbrversiontest/__init__.py <==
# This is straight from setuptools_scm README
from pkg_resources import get_distribution, DistributionNotFound
try:
__version__ = get_distribution(__name__).version
except DistributionNotFound:
# package is not installed
pass
==> pbrversiontest/__main__.py <==
# this isn't required -- only for the demo
import pbrversiontest
print("version is " + pbrversiontest.__version__)
In the development directory, you might have a session like so:
snafu$ python3.6 -mvenv venv/3.6
snafu$ source venv/3.6/bin/activate
(3.6) snafu$ git tag 0.1.2
(3.6) snafu$ pip install -e .
(3.6) snafu$ python -m pbrversiontest
version is 0.1.2
(3.6) snafu$ pip install wheel
(3.6) snafu$ python setup.py bdist_wheel
...
creating 'dist/pbrversiontest-0.1.2-py3-none-any.whl' and adding 'build/bdist.linux-x86_64/wheel' to it
...
(3.6) snafu$ unzip -l dist/pbrversiontest-0.1.2-py3-none-any.whl
Archive: dist/pbrversiontest-0.1.2-py3-none-any.whl
Length Date Time Name
--------- ---------- ----- ----
192 2018-11-25 05:26 pbrversiontest/__init__.py
73 2018-11-25 05:46 pbrversiontest/__main__.py
33 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/AUTHORS
217 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/METADATA
92 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/WHEEL
47 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/pbr.json
15 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/top_level.txt
675 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/RECORD
--------- -------
1344 8 files
P.S. The advantage of a setup like this is that the scm becomes the sole/authoritative source for version tags. That makes it hard for code to misrepresent its version number (or prd/dev/rc status).
– Reece
Nov 28 '18 at 4:56
add a comment |
Consider setuptools_scm, which pulls a version from a git or hg tag when available, or generates an appropriate dev release version (e.g., hgvs-1.2.5.dev6+hb5d989061852.d20181124
). The version is written into package metadata as with a hardcoded version. No non-standard runtime support is needed.
Although I've used setuptools_scm for many projects, I've not used PBR. I was curious and worked up this simple demo:
snafu$ head setup.py setup.cfg pbrversiontest/*.py
==> setup.py <==
from setuptools import setup
setup(
setup_requires=[
"pbr",
"setuptools_scm"
],
pbr=True,
use_scm_version=True,
)
==> setup.cfg <==
[metadata]
name = pbrversiontest
summary = test whether we can use pbr and setuptools_scm
[files]
packages =
pbrversiontest
==> pbrversiontest/__init__.py <==
# This is straight from setuptools_scm README
from pkg_resources import get_distribution, DistributionNotFound
try:
__version__ = get_distribution(__name__).version
except DistributionNotFound:
# package is not installed
pass
==> pbrversiontest/__main__.py <==
# this isn't required -- only for the demo
import pbrversiontest
print("version is " + pbrversiontest.__version__)
In the development directory, you might have a session like so:
snafu$ python3.6 -mvenv venv/3.6
snafu$ source venv/3.6/bin/activate
(3.6) snafu$ git tag 0.1.2
(3.6) snafu$ pip install -e .
(3.6) snafu$ python -m pbrversiontest
version is 0.1.2
(3.6) snafu$ pip install wheel
(3.6) snafu$ python setup.py bdist_wheel
...
creating 'dist/pbrversiontest-0.1.2-py3-none-any.whl' and adding 'build/bdist.linux-x86_64/wheel' to it
...
(3.6) snafu$ unzip -l dist/pbrversiontest-0.1.2-py3-none-any.whl
Archive: dist/pbrversiontest-0.1.2-py3-none-any.whl
Length Date Time Name
--------- ---------- ----- ----
192 2018-11-25 05:26 pbrversiontest/__init__.py
73 2018-11-25 05:46 pbrversiontest/__main__.py
33 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/AUTHORS
217 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/METADATA
92 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/WHEEL
47 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/pbr.json
15 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/top_level.txt
675 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/RECORD
--------- -------
1344 8 files
P.S. The advantage of a setup like this is that the scm becomes the sole/authoritative source for version tags. That makes it hard for code to misrepresent its version number (or prd/dev/rc status).
– Reece
Nov 28 '18 at 4:56
add a comment |
Consider setuptools_scm, which pulls a version from a git or hg tag when available, or generates an appropriate dev release version (e.g., hgvs-1.2.5.dev6+hb5d989061852.d20181124
). The version is written into package metadata as with a hardcoded version. No non-standard runtime support is needed.
Although I've used setuptools_scm for many projects, I've not used PBR. I was curious and worked up this simple demo:
snafu$ head setup.py setup.cfg pbrversiontest/*.py
==> setup.py <==
from setuptools import setup
setup(
setup_requires=[
"pbr",
"setuptools_scm"
],
pbr=True,
use_scm_version=True,
)
==> setup.cfg <==
[metadata]
name = pbrversiontest
summary = test whether we can use pbr and setuptools_scm
[files]
packages =
pbrversiontest
==> pbrversiontest/__init__.py <==
# This is straight from setuptools_scm README
from pkg_resources import get_distribution, DistributionNotFound
try:
__version__ = get_distribution(__name__).version
except DistributionNotFound:
# package is not installed
pass
==> pbrversiontest/__main__.py <==
# this isn't required -- only for the demo
import pbrversiontest
print("version is " + pbrversiontest.__version__)
In the development directory, you might have a session like so:
snafu$ python3.6 -mvenv venv/3.6
snafu$ source venv/3.6/bin/activate
(3.6) snafu$ git tag 0.1.2
(3.6) snafu$ pip install -e .
(3.6) snafu$ python -m pbrversiontest
version is 0.1.2
(3.6) snafu$ pip install wheel
(3.6) snafu$ python setup.py bdist_wheel
...
creating 'dist/pbrversiontest-0.1.2-py3-none-any.whl' and adding 'build/bdist.linux-x86_64/wheel' to it
...
(3.6) snafu$ unzip -l dist/pbrversiontest-0.1.2-py3-none-any.whl
Archive: dist/pbrversiontest-0.1.2-py3-none-any.whl
Length Date Time Name
--------- ---------- ----- ----
192 2018-11-25 05:26 pbrversiontest/__init__.py
73 2018-11-25 05:46 pbrversiontest/__main__.py
33 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/AUTHORS
217 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/METADATA
92 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/WHEEL
47 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/pbr.json
15 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/top_level.txt
675 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/RECORD
--------- -------
1344 8 files
Consider setuptools_scm, which pulls a version from a git or hg tag when available, or generates an appropriate dev release version (e.g., hgvs-1.2.5.dev6+hb5d989061852.d20181124
). The version is written into package metadata as with a hardcoded version. No non-standard runtime support is needed.
Although I've used setuptools_scm for many projects, I've not used PBR. I was curious and worked up this simple demo:
snafu$ head setup.py setup.cfg pbrversiontest/*.py
==> setup.py <==
from setuptools import setup
setup(
setup_requires=[
"pbr",
"setuptools_scm"
],
pbr=True,
use_scm_version=True,
)
==> setup.cfg <==
[metadata]
name = pbrversiontest
summary = test whether we can use pbr and setuptools_scm
[files]
packages =
pbrversiontest
==> pbrversiontest/__init__.py <==
# This is straight from setuptools_scm README
from pkg_resources import get_distribution, DistributionNotFound
try:
__version__ = get_distribution(__name__).version
except DistributionNotFound:
# package is not installed
pass
==> pbrversiontest/__main__.py <==
# this isn't required -- only for the demo
import pbrversiontest
print("version is " + pbrversiontest.__version__)
In the development directory, you might have a session like so:
snafu$ python3.6 -mvenv venv/3.6
snafu$ source venv/3.6/bin/activate
(3.6) snafu$ git tag 0.1.2
(3.6) snafu$ pip install -e .
(3.6) snafu$ python -m pbrversiontest
version is 0.1.2
(3.6) snafu$ pip install wheel
(3.6) snafu$ python setup.py bdist_wheel
...
creating 'dist/pbrversiontest-0.1.2-py3-none-any.whl' and adding 'build/bdist.linux-x86_64/wheel' to it
...
(3.6) snafu$ unzip -l dist/pbrversiontest-0.1.2-py3-none-any.whl
Archive: dist/pbrversiontest-0.1.2-py3-none-any.whl
Length Date Time Name
--------- ---------- ----- ----
192 2018-11-25 05:26 pbrversiontest/__init__.py
73 2018-11-25 05:46 pbrversiontest/__main__.py
33 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/AUTHORS
217 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/METADATA
92 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/WHEEL
47 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/pbr.json
15 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/top_level.txt
675 2018-11-25 06:06 pbrversiontest-0.1.2.dist-info/RECORD
--------- -------
1344 8 files
answered Nov 25 '18 at 6:10
ReeceReece
3,77111733
3,77111733
P.S. The advantage of a setup like this is that the scm becomes the sole/authoritative source for version tags. That makes it hard for code to misrepresent its version number (or prd/dev/rc status).
– Reece
Nov 28 '18 at 4:56
add a comment |
P.S. The advantage of a setup like this is that the scm becomes the sole/authoritative source for version tags. That makes it hard for code to misrepresent its version number (or prd/dev/rc status).
– Reece
Nov 28 '18 at 4:56
P.S. The advantage of a setup like this is that the scm becomes the sole/authoritative source for version tags. That makes it hard for code to misrepresent its version number (or prd/dev/rc status).
– Reece
Nov 28 '18 at 4:56
P.S. The advantage of a setup like this is that the scm becomes the sole/authoritative source for version tags. That makes it hard for code to misrepresent its version number (or prd/dev/rc status).
– Reece
Nov 28 '18 at 4:56
add a comment |
If you are fine with pbr
being a runtime dependency of your package, then you can use the VersionInfo
class from pbr.version
:
from pbr.version import VersionInfo
package_name='my_package'
info = VersionInfo(package_name)
print(info.version_string())
(See also How to load package version into __version__ variable if you are using pbr?)
add a comment |
If you are fine with pbr
being a runtime dependency of your package, then you can use the VersionInfo
class from pbr.version
:
from pbr.version import VersionInfo
package_name='my_package'
info = VersionInfo(package_name)
print(info.version_string())
(See also How to load package version into __version__ variable if you are using pbr?)
add a comment |
If you are fine with pbr
being a runtime dependency of your package, then you can use the VersionInfo
class from pbr.version
:
from pbr.version import VersionInfo
package_name='my_package'
info = VersionInfo(package_name)
print(info.version_string())
(See also How to load package version into __version__ variable if you are using pbr?)
If you are fine with pbr
being a runtime dependency of your package, then you can use the VersionInfo
class from pbr.version
:
from pbr.version import VersionInfo
package_name='my_package'
info = VersionInfo(package_name)
print(info.version_string())
(See also How to load package version into __version__ variable if you are using pbr?)
answered Oct 10 '18 at 12:34
jonathanvernerjonathanverner
11617
11617
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f48383737%2fget-version-from-git-tags-through-pbr%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Isn't
pbr
already an "extra requirement"?– Bailey Parker
Jan 22 '18 at 14:25
It is a requirement, but it is one that I will use for packaging anyways. It gets a lot of its info from git, satisfying the DRY principle (authors, ChangeLog, etc). One of the things it does is generate a version for use in setup.py. Merely looking for a way to leverage that.
– Roy Prins
Jan 22 '18 at 15:14