1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
.. toctree::
: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.
|
