ALTERNATIVES.
CHANGES
=======
0.10.8
------
* Support script text override for newer develop
0.10.7
------
* _get_revno only returns a commit count
0.10.6
------
* Integration test PBR commits
0.10.5
------
* Move write_pbr_json to avoid issues with nose
0.10.4
------
* Properly check for git before getting git dir
* Use post version signifiers
* Only import sphinx during hook processing
0.10.3
------
* Stop including git sha in version strings
* Write and read more complex git sha info
0.10.2
------
* Remove all 2.7 filtering
* Stop filtering out argparse
* Remove mirror testing from the integration script
0.10.1
------
* Prefix git suffixes with + instead of
------
* Remove all 2.7 filtering
* Stop filtering out argparse
* Remove mirror testing from the integration script
0.9.0
-----
* Allow examining parsing exceptions
* Update integration script for Apache 2.4
* Restore Monkeypatched Distribution Instance
* Register testr as a distutil entry point
* Check for git before querying it for a version
* Allow _run_cmd to run commands in any directory
* Make setUp fail if sdist fails
* Permit pre-release versions with git metadata
* Un-nest some sections of code
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.
