Python Build Reasonableness
Go to file
Monty Taylor a9732cf178 Fix a syntax error.
Change-Id: I7725c14698ca3a950000549b36120cd63d29b946
2012-08-03 12:07:53 -05:00
doc/source Fix build failures. 2012-07-13 17:11:03 -05:00
pbr Fix a syntax error. 2012-08-03 12:07:53 -05:00
tools Use pbr, but not via entrypoint hooks. 2012-08-03 12:07:43 -05:00
.coveragerc Initial commit of PBR. 2012-07-12 13:34:03 -05:00
.gitignore Initial commit of PBR. 2012-07-12 13:34:03 -05:00
.gitreview Initial commit of PBR. 2012-07-12 13:34:03 -05:00
README.rst Initial commit of PBR. 2012-07-12 13:34:03 -05:00
setup.cfg Set sensible defaults for sphinx locations. 2012-07-15 09:01:40 -07:00
setup.py Use pbr, but not via entrypoint hooks. 2012-08-03 12:07:43 -05:00
tox.ini Use pbr, but not via entrypoint hooks. 2012-08-03 12:07:43 -05:00

README.rst

:maxdepth 2

PBR: Python Build Reasonablness

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 seems like a good time to make that code into a proper re-usable 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.

What It Does

PBR can and does do a bunch of things for you:

  • Version: Manage version number bad on git revisions and tags
  • AUTHORS: Generate AUTHORS file from git log
  • ChangeLog: Generate ChangeLog from git log
  • Sphinx Autodoc: Generate autodoc stub files for your whole module
  • Requirements: Store your dependencies in a pip requirements file
  • long_description: Use your README file as a long_description

Version

You can tell pbr to manage your version based on git tags. Two different modes are supported, a pre-version mode, in which there is a version your project is working towards a release of, and post-version mode, in which the version between releases is the previous release plus a counter. In both cases, a release is indicated by tagging a revision.

AUTHORS and ChangeLog

Why keep an AUTHORS or a ChangeLog file, when git already has all of the information you need. AUTHORS generation supports filtering/combining based on a standard .mailmap file, as well as looking through commit logs for Signed-off-by lines.

Sphinx Autodoc

Sphinx can produce auto documentation indexes based on signatures and docstrings of your project- but you have to give it index files to tell it to autodoc each module. That's kind of repetitive and boring. PBR will scan your project, find all of your modules, and generate all of the stub files for you.

Requirements

You may not have noticed, but there are differences in how pip requirements.txt files work and how distutils wants to be told about requirements. The pip way is nicer, because it sure does make it easier to popuplate a virtualenv for testing, or to just install everything you need. Duplicating the information, though, is super lame. So PBR will let you keep requirements.txt format files around describing the requirements for your project, will parse them and split them up approprirately, and inject them into the install_requires and/or tests_require and/or dependency_links arguments to setup. Voila!

long_description

There is no need to maintain two long descriptions- and your README file is probably a good long_description. So we'll just inject the contents of your README.rst, README.txt or README file into your empty long_description. Yay for you.

Getting Started

Wow, you're still here? NEAT!

Step one is to add:

setup_requires=['pbr'],

to your setup call in setup.py. Next, change your version= line to:

version="#:",

Don't argue, just do it - there is no valid reason to not use git tags to manage your project version. Unless you want to be ornery, go to the main __init__.py of the module that's the same name as your package - let's call your package "hipsterbeard", and add this code:

from pbr import version
__version_info = version.VersionInfo('hipsterbeard')
__version__ = __version_info.deferred_version_string()

You will now get version information, AUTHORS and ChangeLog and Sphinx stubs generation, and long_description injetion.

Now, if you're weird like openstack and make your python-package something different than your top level code module (such as "I'm going to install python-hipsterbeard and get a thing I can import called hipsterbeard") you'll need to make two slight modifications. First, tell setup where to find your version hooks:

version="#:hipsterbeard:__version_info"

That's the form "Module.submodule:InstanceName" - sort of like nosetests. Then:

from pbr import version
__version_info = version.VersionInfo('python-hipsterbeard')
__version__ = __version_info.deferred_version_string()

goes in hipsterbeard/__init__.py. Mainly that's because pkg-resources needs to look into the egg that setup.py install produced, but your code is called something different, and there is really no other way to figure out what the heck you're doing.

Stop being weird next time. Seriously.

Depends tracking is a little bit easier. The easiest version goes like this:

install_requires=['#:tools/pip-requires'],
tests_require=['#:tools/test-requires'],
dependency_links=['#:tools/pip-requires', '#:tools/test-requires'],

That will put the contents of tools/pip-requires into install_requires, tools/test-requires into tests_require (please someone shoot whoever got the pluralization backwards there) and will split out dependency link information from both files into dependency_links. All three matchers will do what they do on any number of entries that are prefixed by '#:' - so feel free to use that for whatever you'd like.