c01b8dae1e
Stop including git sha in version strings We include it in pbr.json now. Including it is contentious in the world of python, and it's up for debate as to whether or not it provides value. Write and read more complex git sha info Instead of encoding the git sha into the version string, add it to a metadata file. This will allow us to get out of the business of arguing with pip and setuptools about version info. In order to make this really nice, provide a command line utility called "pbr" that has subcommands to print out the metadata that we're now including in the egg-info dir. Only import sphinx during hook processing When pbr is imported to handle writing the egg_info file because of the entry point, it's causing sphinx to get imported. This has a cascading effect once docutils is trying to be installed on a system with pbr installed. If some of the imports fail along the way, allow pbr to continue usefully but without the Sphinx extensions available. Eventually, when everything is installed, those extensions will work again when the commands for build_sphinx, etc. are run separately. Also slip in a change to reorder the default list of environments run by tox so the testr database is created using a dbm format available to all python versions. Integration test PBR commits Make sure that if a PBR commit is being tested then we install and use that source rather than the latest PBR release. Change-Id: Ie121e795be2eef30822daaa5fe8ab1c2315577ae (cherry picked from commit |
||
---|---|---|
doc/source | ||
pbr | ||
tools | ||
.gitignore | ||
.gitreview | ||
.mailmap | ||
.testr.conf | ||
CONTRIBUTING.rst | ||
LICENSE | ||
MANIFEST.in | ||
README.rst | ||
requirements.txt | ||
setup.cfg | ||
setup.py | ||
test-requirements.txt | ||
tox.ini |
README.rst
Introduction
PBR is a library that injects some useful and sensible default behaviors into your setuptools run. It started off life as the chunks of code that were copied between all of the OpenStack projects. Around the time that OpenStack hit 18 different projects each with at least 3 active branches, it seemed like a good time to make that code into a proper reusable library.
PBR is only mildly configurable. The basic idea is that there's a decent way to run things and if you do, you should reap the rewards, because then it's simple and repeatable. If you want to do things differently, cool! But you've already got the power of Python at your fingertips, so you don't really need PBR.
PBR builds on top of the work that d2to1 started to provide for declarative configuration. d2to1 is itself an implementation of the ideas behind distutils2. Although distutils2 is now abandoned in favor of work towards PEP 426 and Metadata 2.0, declarative config is still a great idea and specifically important in trying to distribute setup code as a library when that library itself will alter how the setup is processed. As Metadata 2.0 and other modern Python packaging PEPs come out, PBR aims to support them as quickly as possible.
You can read more in the documentation.
Bugs are tracked using launchpad.