[4352] | 1 | Developer Notes |
---|
| 2 | *************** |
---|
| 3 | |
---|
[4978] | 4 | How to setup a developer instance of the WAeUP SIRP, handle tests, docs |
---|
[4352] | 5 | etc. |
---|
| 6 | |
---|
[4978] | 7 | The new WAeUP SIRP is based on `Grok <http://grok.zope.org/>`_. |
---|
[4352] | 8 | |
---|
| 9 | Installing a developer copy |
---|
| 10 | =========================== |
---|
| 11 | |
---|
| 12 | The installation is described for Linux-based computers. |
---|
| 13 | |
---|
| 14 | Preparing the system |
---|
| 15 | -------------------- |
---|
| 16 | |
---|
[4978] | 17 | To create a working copy of the WAeUP SIRP we recommend use of |
---|
[4352] | 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 | |
---|
[4355] | 37 | * enscript (enscript) [optional] |
---|
| 38 | |
---|
| 39 | This is only needed if you want test coverage reports. |
---|
| 40 | |
---|
[4352] | 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 \ |
---|
[4355] | 44 | gcc libc6-dev svn enscript |
---|
[4352] | 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 |
---|
[4978] | 129 | sources of the WAeUP SIRP from the subversion server:: |
---|
[4352] | 130 | |
---|
| 131 | $ cd mysandbox/ |
---|
[4978] | 132 | $ svn co https://svn.waeup.org/repos/main/waeup.sirp/trunk waeup-trunk |
---|
[4352] | 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 | |
---|
[4978] | 196 | With the :mod:`waeup.sirp` package we try to reach high standards in |
---|
| 197 | both, documentation and testing. |
---|
[4352] | 198 | |
---|
[4978] | 199 | :mod:`waeup.sirp` makes extensive use of doctests, which this way also |
---|
[4352] | 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 | |
---|
[4978] | 208 | The documentation of the :mod:`waeup.sirp` project can easily be |
---|
| 209 | created doing:: |
---|
[4352] | 210 | |
---|
| 211 | $ bin/waeupdocs |
---|
| 212 | |
---|
| 213 | This will create a tree of HTML pages in |
---|
[4978] | 214 | ``parts/waeupdocs/waeup.sirp/build/waeup.sirp/`` which you can for |
---|
| 215 | instance browse by pointing your browser to this location. |
---|
[4352] | 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 |
---|
[4978] | 225 | at the same time. See the many .txt files in the :mod:`waeup.sirp` |
---|
| 226 | package for examples. |
---|
[4352] | 227 | |
---|
| 228 | |
---|
| 229 | Testing |
---|
| 230 | ======= |
---|
| 231 | |
---|
[4978] | 232 | Tests are most important to the reliability of the :mod:`waeup.sirp` |
---|
[4352] | 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 | |
---|
[4978] | 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:: |
---|
[4352] | 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 | |
---|
[4355] | 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 | |
---|
[4359] | 298 | $ bin/coverage |
---|
[4355] | 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. |
---|