1 | Developer Notes |
---|
2 | *************** |
---|
3 | |
---|
4 | How to setup a developer instance of the WAeUP SIRP, handle tests, docs |
---|
5 | etc. |
---|
6 | |
---|
7 | The new WAeUP SIRP is based on `Grok <http://grok.zope.org/>`_. |
---|
8 | |
---|
9 | Installing a developer copy |
---|
10 | =========================== |
---|
11 | |
---|
12 | The installation is described for Linux-based computers. |
---|
13 | |
---|
14 | Preparing the system |
---|
15 | -------------------- |
---|
16 | |
---|
17 | To create a working copy of the WAeUP SIRP we recommend use of |
---|
18 | `virtualenv`. You, however, need also some basic libraries, a C |
---|
19 | compiler and some things more. |
---|
20 | |
---|
21 | What you need (Debian/Ubuntu package names in brackets): |
---|
22 | |
---|
23 | * Python 2.5 (python2.5) |
---|
24 | |
---|
25 | Currently, also Python2.4 is supported but we want to make use of |
---|
26 | some of the 2.5 goodies in the future. |
---|
27 | |
---|
28 | |
---|
29 | * Python 2.5 development files (python2.5-dev) |
---|
30 | |
---|
31 | * A C-Compiler (gcc) |
---|
32 | |
---|
33 | * The C library development files (libc6-dev) |
---|
34 | |
---|
35 | * A subversion client (svn) |
---|
36 | |
---|
37 | * enscript (enscript) [optional] |
---|
38 | |
---|
39 | This is only needed if you want test coverage reports. |
---|
40 | |
---|
41 | All these packages can be installed on Debian systems like this:: |
---|
42 | |
---|
43 | # apt-get install python2.5 python2.5-dev python2.5-dbg \ |
---|
44 | gcc libc6-dev svn enscript |
---|
45 | |
---|
46 | Afterwards you should be able to enter:: |
---|
47 | |
---|
48 | $ python2.5 |
---|
49 | |
---|
50 | at the commandline and get a Python prompt. Quit the interpreter |
---|
51 | pressing <CTRL-D>. |
---|
52 | |
---|
53 | Installing `virtualenv` |
---|
54 | ----------------------- |
---|
55 | |
---|
56 | We recommend use of `virtualenv` to create Python sandboxes where you |
---|
57 | can run your code without touching any other installations. |
---|
58 | |
---|
59 | If you don't already have ``easy_install`` available, you can find the |
---|
60 | script to set it up on the `PEAK EasyInstall page`_. |
---|
61 | |
---|
62 | .. _`PEAK EasyInstall page`: http://peak.telecommunity.com/DevCenter/EasyInstall#installing-easy-install |
---|
63 | |
---|
64 | You need to download `ez_setup.py`_. Then, you run it like this to |
---|
65 | install ``easy_install`` into your system Python:: |
---|
66 | |
---|
67 | $ sudo python2.5 ez_setup.py |
---|
68 | |
---|
69 | .. _`ez_setup.py`: http://peak.telecommunity.com/dist/ez_setup.py |
---|
70 | |
---|
71 | This will make ``easy_install`` available to you. |
---|
72 | |
---|
73 | .. note:: Sometimes you have ``easy_install`` installed but you need a |
---|
74 | newer version of the underlying setuptools infrastructure to |
---|
75 | make Grok work. You can upgrade setuptools with:: |
---|
76 | |
---|
77 | $ sudo easy_install -U setuptools |
---|
78 | |
---|
79 | Now you can install `virtualenv` by doing (as root):: |
---|
80 | |
---|
81 | # easy_install-2.5 virtualenv |
---|
82 | |
---|
83 | This step will fetch all needed sources from the internet and install |
---|
84 | `virtualenv` locally in your Python2.5 installation. |
---|
85 | |
---|
86 | |
---|
87 | Creating a sandbox |
---|
88 | ------------------ |
---|
89 | |
---|
90 | This step is only necessary (and recommended) if you installed |
---|
91 | `virtualenv` before. |
---|
92 | |
---|
93 | As a normal user you now can create a sandbox for your upcoming work |
---|
94 | by:: |
---|
95 | |
---|
96 | $ virtualenv --no-site-packages mysandbox |
---|
97 | |
---|
98 | where ``mysandbox`` is a directory in the filesystem where your |
---|
99 | sandbox will be created. `virtualenv` will also create this directory |
---|
100 | for you. |
---|
101 | |
---|
102 | By passing the ``no-site-packages`` switch we tell `virtualenv` to |
---|
103 | provide us a clean environment without any extra-packages installed |
---|
104 | systemwide. |
---|
105 | |
---|
106 | If you have a look into the freshly created sandbox, you will notice |
---|
107 | that in the ``bin/`` directory there is also |
---|
108 | |
---|
109 | You now can activate the sandbox by doing:: |
---|
110 | |
---|
111 | $ source mysandbox/bin/activate |
---|
112 | |
---|
113 | You will notice that the input prompt changes. |
---|
114 | |
---|
115 | To deactivate the sandbox at any time, enter:: |
---|
116 | |
---|
117 | $ deactivate |
---|
118 | |
---|
119 | and the prompt will be the same as before the activation. |
---|
120 | |
---|
121 | For the following steps make sure the sandbox is active. |
---|
122 | |
---|
123 | |
---|
124 | Creating a working place |
---|
125 | ------------------------ |
---|
126 | |
---|
127 | In the sandbox (or anywhere else) we now create our real working |
---|
128 | environment. To do this, we change to the sandbox and checkout the |
---|
129 | sources of the WAeUP SIRP from the subversion server:: |
---|
130 | |
---|
131 | $ cd mysandbox/ |
---|
132 | $ svn co https://svn.waeup.org/repos/main/waeup.sirp/trunk waeup-trunk |
---|
133 | |
---|
134 | where ``waeup-trunk`` is only a name we've chosen here to make clear |
---|
135 | where the sources come from. |
---|
136 | |
---|
137 | This command should fetch the sources of the WAeUP sources for you and |
---|
138 | put it in the directory ``waeup-trunk/``. |
---|
139 | |
---|
140 | Now enter the new directory:: |
---|
141 | |
---|
142 | $ cd waeup-trunk |
---|
143 | |
---|
144 | |
---|
145 | Preparing the build |
---|
146 | ------------------- |
---|
147 | |
---|
148 | In the sources directory (``waeup-trunk/``) you have to prepare the |
---|
149 | project to fetch needed components (eggs), compile C-code parts, |
---|
150 | etc. This steip will not touch any external projects:: |
---|
151 | |
---|
152 | $ python2.5 bootstrap.py |
---|
153 | |
---|
154 | This will generate some directories and the ``buildout`` script in |
---|
155 | ``bin/`` for us. This step must be executed only once for each |
---|
156 | instance. |
---|
157 | |
---|
158 | Now we can do the real build by triggering:: |
---|
159 | |
---|
160 | $ bin/buildout |
---|
161 | |
---|
162 | If this is your first install of some Grok-related project, this step |
---|
163 | will need some time as lots of sources have to be fetched, many |
---|
164 | components must be compiled, etc. |
---|
165 | |
---|
166 | This step must be redone whenever you change something in |
---|
167 | ``buildout.cfg`` or ``setup.py``. |
---|
168 | |
---|
169 | Afterwards we are ready to go. |
---|
170 | |
---|
171 | |
---|
172 | Start the instance |
---|
173 | ------------------ |
---|
174 | |
---|
175 | You should be able now to start the created instance by doing:: |
---|
176 | |
---|
177 | $ bin/zopectl fg |
---|
178 | |
---|
179 | If you now point a browser to:: |
---|
180 | |
---|
181 | localhost:8080 |
---|
182 | |
---|
183 | you should get a login pop-up, where you can login as superuser with |
---|
184 | ``grok`` and ``grok`` as username/password. |
---|
185 | |
---|
186 | If you want to change the default credentials, have a look into |
---|
187 | ``buildout.cfg`` where the superuser password is determined. |
---|
188 | |
---|
189 | You can stop the instance by pressing <CTRL-C>. |
---|
190 | |
---|
191 | |
---|
192 | |
---|
193 | Documentation |
---|
194 | ============= |
---|
195 | |
---|
196 | With the :mod:`waeup.sirp` package we try to reach high standards in |
---|
197 | both, documentation and testing. |
---|
198 | |
---|
199 | :mod:`waeup.sirp` makes extensive use of doctests, which this way also |
---|
200 | become both: executable (i.e. testable) examples and documentation. |
---|
201 | |
---|
202 | Generating documentation |
---|
203 | ------------------------ |
---|
204 | |
---|
205 | We use the excellent `Sphinx <http://sphinx.pocoo.org/>`_ Python |
---|
206 | documentation generator to generate the docs as HTML pages. |
---|
207 | |
---|
208 | The documentation of the :mod:`waeup.sirp` project can easily be |
---|
209 | created doing:: |
---|
210 | |
---|
211 | $ bin/waeupdocs |
---|
212 | |
---|
213 | This will create a tree of HTML pages in |
---|
214 | ``parts/waeupdocs/waeup.sirp/build/waeup.sirp/`` which you can for |
---|
215 | instance browse by pointing your browser to this location. |
---|
216 | |
---|
217 | An 'official' place in internet for the whole docs is about to come |
---|
218 | but not yet available. |
---|
219 | |
---|
220 | |
---|
221 | Writing documentation |
---|
222 | --------------------- |
---|
223 | |
---|
224 | means explaining to other developers what your code does and test it |
---|
225 | at the same time. See the many .txt files in the :mod:`waeup.sirp` |
---|
226 | package for examples. |
---|
227 | |
---|
228 | |
---|
229 | Testing |
---|
230 | ======= |
---|
231 | |
---|
232 | Tests are most important to the reliability of the :mod:`waeup.sirp` |
---|
233 | package. We don't tell someone that our code works, if we cannot prove |
---|
234 | it. And we prove it by testing. |
---|
235 | |
---|
236 | Running tests |
---|
237 | ------------- |
---|
238 | |
---|
239 | You can run all the tests for the package by doing:: |
---|
240 | |
---|
241 | $ bin/test |
---|
242 | |
---|
243 | If you like colored output (can improve readability of failure |
---|
244 | messages), use the ``-c`` switch:: |
---|
245 | |
---|
246 | $ bin/test -c |
---|
247 | |
---|
248 | We have many tests in the :mod:`waeup.sirp` package so that sometimes |
---|
249 | you only want the functional *or* the unit tests to run. This can be |
---|
250 | done like this:: |
---|
251 | |
---|
252 | $ bin/test -c -u |
---|
253 | |
---|
254 | if you want only unit tests or like this:: |
---|
255 | |
---|
256 | $ bin/test -c -f |
---|
257 | |
---|
258 | if you only want functional tests. |
---|
259 | |
---|
260 | |
---|
261 | Writing tests |
---|
262 | ------------- |
---|
263 | |
---|
264 | Is a wiiide topic. For now, please see the numerous .txt files in the |
---|
265 | source. Most of the **are** tests. |
---|
266 | |
---|
267 | Code coverage |
---|
268 | ------------- |
---|
269 | |
---|
270 | We want to make sure, that all aspects of our software are |
---|
271 | tested. This means, that all parts of the codes should be tested |
---|
272 | somewhere. |
---|
273 | |
---|
274 | To tell how good our test coverage is, we can also use the testrunner |
---|
275 | (``bin/test``):: |
---|
276 | |
---|
277 | $ bin/test --coverage=coverage |
---|
278 | |
---|
279 | will run the tests but also look, which parts of code were touched by |
---|
280 | them. For releases we want 100% coverage. Beware: running tests with |
---|
281 | the ``--coverage`` switch slows down tests by factor 10 or more. |
---|
282 | |
---|
283 | The command above will output a table with percentages. Furthermore, |
---|
284 | in ``/parts/test/coverage`` you will (after the testrun) find your |
---|
285 | sources preceeded by markers which tell, how often (or none) a certain |
---|
286 | line was used in tests. |
---|
287 | |
---|
288 | To have a more convenient cmdline interface, we also provide some |
---|
289 | shortcuts:: |
---|
290 | |
---|
291 | $ bin/coverage-detect |
---|
292 | |
---|
293 | will run all the tests as shown above and put the results in |
---|
294 | ``parts/coverage-detect/coverage``. |
---|
295 | |
---|
296 | After that you can run:: |
---|
297 | |
---|
298 | $ bin/coverage |
---|
299 | |
---|
300 | to get a browsable HTML representation of test coverage in |
---|
301 | ``parts/coverage-detect/coverage/report``. |
---|
302 | |
---|
303 | Both, the coverage reports and HTML documentation generated by sphinx |
---|
304 | can be packed and put onto a website as-is. |
---|
305 | |
---|
306 | It is also possible to generate the docs and reports nightly by a |
---|
307 | buildbot or something like this. |
---|