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
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Foreword: Why Paver? — Paver 1.2.1 documentation</title>
<link rel="stylesheet" href="_static/default.css" type="text/css" />
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: './',
VERSION: '1.2.1',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="_static/jquery.js"></script>
<script type="text/javascript" src="_static/underscore.js"></script>
<script type="text/javascript" src="_static/doctools.js"></script>
<link rel="top" title="Paver 1.2.1 documentation" href="index.html" />
<link rel="next" title="Paver’s Features" href="features.html" />
<link rel="prev" title="Paver: Easy Scripting for Software Projects" href="index.html" />
</head>
<body>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
accesskey="I">index</a></li>
<li class="right" >
<a href="py-modindex.html" title="Python Module Index"
>modules</a> |</li>
<li class="right" >
<a href="features.html" title="Paver’s Features"
accesskey="N">next</a> |</li>
<li class="right" >
<a href="index.html" title="Paver: Easy Scripting for Software Projects"
accesskey="P">previous</a> |</li>
<li><a href="index.html">Paver 1.2.1 documentation</a> »</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body">
<div class="section" id="foreword-why-paver">
<h1>Foreword: Why Paver?<a class="headerlink" href="#foreword-why-paver" title="Permalink to this headline">¶</a></h1>
<blockquote>
<div><p>Paver occupies a sweet spot in the python toolset, the design is sound,
it’s easier than mud to work with at a basic level, and it has a nice grade
of descent into more advanced things.</p>
<p class="attribution">—David Eyk</p>
</div></blockquote>
<p>I didn’t want to make a new build tool. Honestly. The main reason that I created Paver
is...</p>
<div class="section" id="the-declarative-imperative-divide">
<h2>The Declarative/Imperative Divide<a class="headerlink" href="#the-declarative-imperative-divide" title="Permalink to this headline">¶</a></h2>
<p>When you solve the same problem repeatedly, patterns emerge and you’re able to easily
see ways to reduce how much effort is involved in solving that problem. Often
times, you’ll end up with a <a class="reference external" href="http://en.wikipedia.org/wiki/Declarative_programming">declarative solution</a>. Python’s standard distutils
is a declarative solution. In your call to the <tt class="docutils literal"><span class="pre">setup()</span></tt> function, you declare
some metadata about your project and provide a list of the parts and you end
up with a nice command line interface. That command line interface knows how to
make redistributable tarballs (and eggs if you have setuptools), install the
package, build C extensions and more.</p>
<p>zc.buildout does a similar thing for deployments. Declare the parts of your system
and specify a recipe for each part (each recipe with its own collection of options)
and you can build up a consistent system with one command.</p>
<p>These tools sound great, don’t they? They are great. As long as you don’t need
to customize the capabilities they provide. For example, it’s not uncommon that
you’ll need to move some file here, create some directory there, etc. Then what?</p>
<p>In an <a class="reference external" href="http://en.wikipedia.org/wiki/Imperative_programming">imperative system</a>, you’d just add the few lines of code you need.</p>
<p>For distutils and zc.builout and other similar tools, the answer usually involves
extra boilerplate surrounding the code in question and then installing that code somewhere. You basically have to create declarative syntax for something that is a one-off rather than a larger, well-understood problem. And, for distutils and zc.buildout, you have to use two entirely different mechanisms.</p>
</div>
<div class="section" id="consistency-for-project-related-tasks">
<h2>Consistency for Project Related Tasks<a class="headerlink" href="#consistency-for-project-related-tasks" title="Permalink to this headline">¶</a></h2>
<p>And that’s the next thing that bothered me with the state of Python tools. It
would be nice to have a consistent interface in command line and configuration
for the tools that I use to work with my projects. Every tool I bring in to
the project adds new command line interfaces, more config files (and some of
those config files duplicate project metadata!).</p>
</div>
<div class="section" id="that-s-why-paver-is-here">
<h2>That’s Why Paver Is Here<a class="headerlink" href="#that-s-why-paver-is-here" title="Permalink to this headline">¶</a></h2>
<p>Paver is set up to provide declarative handling of common tasks with as easy
an escape hatch to imperative programming as possible (just add a function
with a decorator in the same file). Your project-related configuration
options are all together and all accessible to different parts of your
build and deployment setup. And the language used for everything is Python,
so you’re not left guessing how to do a <tt class="docutils literal"><span class="pre">for</span></tt> loop.</p>
<p>Of course, rebuilding the great infrastructure provided by tools like distutils
makes no sense. So, Paver just uses distutils and other tools directly.</p>
<p>Paver also goes beyond just providing an extension mechanism for distutils.
It adds a bunch of useful capabilities for things like working with files
and directories, elegantly handling sample code for your documentation and
building bootstrap scripts to allow your software to easily be installed
in an isolated virtualenv.</p>
<p>I’m already using Paver for SitePen’s Support service user interface
project and I use Paver to manage Paver itself! It’s been working out
great for me, and it’s set up in such a way that whatever kind of scripting
your project needs it should be pretty simple with Paver.</p>
</div>
<div class="section" id="making-the-switch-is-easy">
<h2>Making the Switch is Easy<a class="headerlink" href="#making-the-switch-is-easy" title="Permalink to this headline">¶</a></h2>
<p>Finally, I’ve put some time into making sure that moving a project from
distutils to Paver is easy for everyone involved (people making the
projects and people using the projects). Check out the
<a class="reference internal" href="getting_started.html#gettingstarted"><em>Getting Started Guide</em></a> to see an example of how
a project moves from distutils to Paver (even maintaining the
<tt class="docutils literal"><span class="pre">python</span> <span class="pre">setup.py</span> <span class="pre">install</span></tt> command that everyone’s used to!)</p>
<p>Thanks for reading!</p>
<p>Kevin Dangoor
May 2008</p>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<h3><a href="index.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Foreword: Why Paver?</a><ul>
<li><a class="reference internal" href="#the-declarative-imperative-divide">The Declarative/Imperative Divide</a></li>
<li><a class="reference internal" href="#consistency-for-project-related-tasks">Consistency for Project Related Tasks</a></li>
<li><a class="reference internal" href="#that-s-why-paver-is-here">That’s Why Paver Is Here</a></li>
<li><a class="reference internal" href="#making-the-switch-is-easy">Making the Switch is Easy</a></li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<p class="topless"><a href="index.html"
title="previous chapter">Paver: Easy Scripting for Software Projects</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="features.html"
title="next chapter">Paver’s Features</a></p>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="_sources/foreword.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
>index</a></li>
<li class="right" >
<a href="py-modindex.html" title="Python Module Index"
>modules</a> |</li>
<li class="right" >
<a href="features.html" title="Paver’s Features"
>next</a> |</li>
<li class="right" >
<a href="index.html" title="Paver: Easy Scripting for Software Projects"
>previous</a> |</li>
<li><a href="index.html">Paver 1.2.1 documentation</a> »</li>
</ul>
</div>
<div class="footer">
© Copyright 2008, SitePen, Inc..
Last updated on Jun 02, 2013.
Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2b1.
</div>
</body>
</html>
|
