~therp-nl/anybox.recipe.openerp/jbaudoux-relative_paths_resolve_conflict

« back to all changes in this revision

Viewing changes to doc/configuration.rst

[MRG] Update with target branch

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
anybox.recipe.openerp
2
 
=====================
 
1
Configuration reference
 
2
=======================
3
3
 
4
4
This is a `Buildout <https://github.com/buildout/buildout>`_ recipe that can
5
5
download, install and configure one or several OpenERP servers, web clients,
8
8
with gunicorn deployment and an additional cron worker. It works under Linux
9
9
and MacOs. It might work under Windows but it is untested.
10
10
 
11
 
For a **quickstart** you can jump to the howto_ section.
12
 
 
13
11
A "Buildout recipe" is the engine behind a Buildout "part". A "buildout part"
14
12
is a part of a larger application built with the Buildout sandbox build system.
15
13
Using Buildout is harmless for your system because it is entirely
17
15
buildout is gone. You never have to use administrative rights, except for
18
16
build dependencies.
19
17
 
20
 
.. contents::
21
 
 
22
 
Recipes
23
 
~~~~~~~
24
 
 
25
 
You get 3 recipes at once. The recipe to use is the following:
26
 
 
27
 
For the server::
 
18
.. _buildout_conf_parts:
 
19
 
 
20
The buildout configuration file and parts
 
21
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
22
The intents of this section is to highlights a few facts that we've
 
23
found especially useful. People should refer to the
 
24
`reference zc.buildout documentation
 
25
<https://pypi.python.org/pypi/zc.buildout/2.2.1>`_
 
26
and in particular to the `configuration file syntax
 
27
<https://pypi.python.org/pypi/zc.buildout/2.2.1#configuration-file-syntax>`_
 
28
(these links may have to be adapted for the version in use).
 
29
 
 
30
 
 
31
Buildout configuration files are written almost in INI format, and
 
32
always start with a ``buildout`` section::
 
33
 
 
34
  [buildout]
 
35
  parts = openerp
 
36
 
 
37
The ``parts`` option specifies which parts to install by default if
 
38
one runs ``bin/buildout`` with no explicit ``install`` directive.
 
39
 
 
40
Parts directly correspond to sections of the configuration file, and
 
41
must specify the recipe that's to be used::
 
42
 
 
43
  [openerp]
 
44
  recipe = anybox.recipe.openerp:server
 
45
 
 
46
An extra dependency of the recipe gets required at runtime like this::
 
47
 
 
48
  recipe = anybox.recipe.openerp[bzr]:server
 
49
 
 
50
Command line
 
51
------------
 
52
The configuration file can be specified from the command line::
 
53
 
 
54
  bin/buildout -c buildout.local.cfg
 
55
 
 
56
Recipe options can be overridden from the command-line::
 
57
 
 
58
  bin/buildout -c buildout.local.cfg openerp:clean=True openerp:xmlrpc_port=8169
 
59
 
 
60
Parts that are not listed in the ``buildout`` configuration section
 
61
can be explicitely installed::
 
62
 
 
63
  bin/buildout install openerp funkload static-analysis
 
64
 
 
65
.. _extends:
 
66
 
 
67
Inheritance
 
68
-----------
 
69
 
 
70
A buildout configuration file can reference another one and change
 
71
some options (note the ``+=`` notation that's not part of the INI format)::
 
72
 
 
73
  [buildout]
 
74
  extends = buildout.base.cfg
 
75
 
 
76
  [openerp]
 
77
  eggs += nose
 
78
          coverage
 
79
  with_devtools = True
 
80
 
 
81
These extensions can be chained. This allows in particular project maintainers
 
82
to separate the configuration options that are considered to be part
 
83
of the project from those that depend on the server environment
 
84
(ports, database hosts…)
 
85
 
 
86
Default configuration
 
87
---------------------
 
88
 
 
89
If available, the settings from ``$HOME/.buildout/default.cfg`` always
 
90
apply, as if it where the default value of the :ref:`extends <extends>` option.
 
91
 
 
92
This is commonly used with the ``eggs-directory`` and
 
93
:ref:`openerp-downloads-directory` options, because these amount to create a
 
94
user-level cache.
 
95
 
 
96
Finally, you may also use :ref:`extends <extends>` in ``default.cfg`` to point
 
97
to a system-wide configuration file (useful to enforce
 
98
policies at the organization or physical site level, such as local
 
99
index servers, mirrors, etc.).
 
100
 
 
101
 
 
102
OpenERP recipes
 
103
~~~~~~~~~~~~~~~
 
104
 
 
105
There are three different recipes bundled with
 
106
``anybox.recipe.openerp``. The option line to put in your part (see
 
107
:ref:`buildout_conf_parts`) is the following.
 
108
 
 
109
Server
 
110
------
 
111
::
28
112
 
29
113
    recipe = anybox.recipe.openerp:server
30
114
 
31
 
For the web client::
 
115
.. note:: If you plan on using Launchpad's short Bazaar branch notation
 
116
          (``lp:``), then you need to add the ``bzr`` extra-dependency::
 
117
 
 
118
            recipe = anybox.recipe.openerp[bzr]:server
 
119
 
 
120
Web client
 
121
----------
 
122
::
32
123
 
33
124
    recipe = anybox.recipe.openerp:webclient
34
125
 
35
 
For the gtk client::
 
126
GTK client
 
127
----------
 
128
::
36
129
 
37
130
    recipe = anybox.recipe.openerp:gtkclient
38
131
 
39
 
Default options from zc.recipe.egg
40
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
41
 
 
42
 
This recipe reuses the *zc.recipe.egg:scripts* recipe, so the options
43
 
are the same (*eggs*, *interpreter*, etc.), and some changes, documented below.
44
 
 
45
 
Consult the documentation here http://pypi.python.org/pypi/zc.recipe.egg
46
 
 
47
 
The main useful ones are below:
48
 
 
49
 
eggs
50
 
----
51
 
 
52
 
Starting from version 0.16 of the recipe, you don't need to put anything in
53
 
this option by default. But you may specify additional eggs needed by addons,
54
 
or just useful ones::
55
 
 
56
 
    eggs = 
57
 
        ipython
58
 
        openobject-library
59
 
 
60
 
scripts
61
 
-------
62
 
.. note:: for scripts needing to call OpenERP internal API or to load
63
 
          an OpenERP database prior to execution, check
64
 
          ``openerp_scripts`` below.
65
 
 
66
 
The behaviour of this option is slightly modified :
67
 
by default, no script other than those directly related to OpenERP are
68
 
generated, but you may specify some explicitely, with the same semantics as the
69
 
normal behaviour (we simply set an empty default value, which means to not
70
 
produce scripts)::
71
 
 
72
 
        scripts =
73
 
            change_tz
74
 
 
75
 
In the current state, beware to *not* require the same script in different
76
 
parts or rename them. See
77
 
https://bugs.launchpad.net/anybox.recipe.openerp/+bug/1020967 for
78
 
details.
79
 
 
80
 
interpreter
81
 
-----------
82
 
With the ``gtklcient`` and ``webclient`` recipes,
83
 
this is the default `interpreter` option of `zc.recipe.egg` that
84
 
specifies the name of the Python interpreter that shoud be included in
85
 
the``bin`` directory of the buildout::
86
 
 
87
 
    interpreter = erp_python
88
 
 
89
 
With the ``server`` recipe, the ``interpreter`` option will be ignored,
90
 
because it always creates an interpreter with preloaded objects to
91
 
bootstrap openerp. Check the ``interpreter_name`` option below for
92
 
more details.
93
 
 
94
 
 
95
 
Specific options
96
 
~~~~~~~~~~~~~~~~
97
 
 
98
 
The recipe also adds a few specific options:
 
132
.. note:: from OpenERP 7.0 onwards, the web and gtk clients aren't
 
133
          that useful anymore.
 
134
 
 
135
Options for assembly and source management
 
136
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
137
 
 
138
.. _version:
99
139
 
100
140
version
101
141
-------
102
142
 
103
143
Specifies the OpenERP version to use. It can be:
104
144
 
105
 
The **version number** of an official OpenERP (server, web client or gtk client)::
106
 
 
107
 
  version = 6.0.3
108
 
 
109
 
A **custom download**::
110
 
 
111
 
  version = url http://example.com/openerp.tar.gz
112
 
 
113
 
An absolute or a relative **path**::
114
 
 
115
 
  version = path /my/path/to/a/custom/openerp
116
 
 
117
 
A custom **bzr, hg, git or svn** branch or repository. The syntax is the same
118
 
as the `addons` option (see below)::
119
 
 
120
 
  version = bzr lp:openobject-server/6.1 openerp61 last:1
121
 
 
122
 
A **nightly** build::
123
 
 
124
 
  version = nightly 6.1 20120814-233345
125
 
 
126
 
or (dangerously unpinned version)::
127
 
 
128
 
  version = nightly 6.1 latest
129
 
 
130
 
or even more dangerous::
131
 
 
132
 
  version = nightly trunk latest
133
 
 
 
145
* The **version number** of an official OpenERP (server, web client or gtk client)::
 
146
 
 
147
    version = 6.0.3
 
148
 
 
149
* A **custom download**::
 
150
 
 
151
    version = url http://example.com/openerp.tar.gz
 
152
 
 
153
* An absolute or a relative **path**::
 
154
 
 
155
    version = path /my/path/to/a/custom/openerp
 
156
 
 
157
* A custom **bzr, hg, git or svn** branch or repository. The syntax is the same
 
158
  as with the :ref:`addons` option::
 
159
 
 
160
    recipe = anybox.recipe.openerp[bzr]:server
 
161
    version = bzr lp:openobject-server/6.1 openerp61 last:1
 
162
 
 
163
  .. note:: the ``[bzr]`` extra dependency declaration is useful for
 
164
            resolution of the ``lp:`` address shortcuts.
 
165
 
 
166
* A **nightly** build::
 
167
 
 
168
    version = nightly 6.1 20120814-233345
 
169
 
 
170
* or (dangerously unpinned version)::
 
171
 
 
172
    version = nightly 6.1 latest
 
173
 
 
174
*  or even more dangerous::
 
175
 
 
176
     version = nightly trunk latest
 
177
 
 
178
.. _addons:
134
179
 
135
180
addons
136
181
------
139
184
 
140
185
Example::
141
186
 
 
187
  recipe = anybox.recipe.openerp[bzr]:server
142
188
  addons = local ../some/relative/path/for/custom_addons/
143
189
           local /some/other/absolute/path/for/custom_addons
144
190
           bzr lp:openobject-addons/trunk/    addons0 last:1
151
197
addons, or a single addon. In that latter case, it will be actually
152
198
placed one directory below.
153
199
 
 
200
.. note:: the ``[bzr]`` extra-dependency declaration as showcased
 
201
          above in the ``recipe`` line is necessary for
 
202
          resolution of ``lp:`` launchpad address shortcuts.
 
203
 
154
204
.. warning::
155
205
 
156
206
   Never name one of these addons directory simply ``addons``. It
159
209
 
160
210
For remote repositories, the syntax is:
161
211
 
162
 
``TYPE  URL  DESTINATION  REVISION  [OPTIONS]``
163
 
 
164
 
* *TYPE* can be ``bzr``, ``hg``, ``git`` or ``svn``
165
 
* *URL* is any URL scheme supported by the versionning tool
166
 
* *DESTINATION* is the local directory that will be created (relative or absolute)
167
 
* *REVISION* is any version specification supported (revision, tag, etc.)
168
 
* *OPTIONS* take the form ``name=value``. Currently the ``subdir``
169
 
  option is recognized. If used, the given subdirectory of the
170
 
  repository is registered as an addons directory.
 
212
    ``TYPE  URL  DESTINATION  REVISION  [OPTIONS]``
 
213
 
 
214
with the following semantics:
 
215
 
 
216
:TYPE: one of ``bzr``, ``hg``, ``git`` or ``svn``
 
217
:URL: is any URL scheme supported by the versionning tool
 
218
:DESTINATION: is the local directory that will be created (relative or absolute)
 
219
:REVISION: is any version specification supported (revision, tag, etc.)
 
220
:OPTIONS: each one takes the form ``name=value``. No whitespace is
 
221
          allowed inside an option, and no escaping is
 
222
          implemented.
171
223
 
172
224
Repositories are updated on each build according to the specified
173
225
revision. You must be careful with the revision specification.
176
228
specified revision is performed, if the VCS allows it (Subversion does
177
229
not).
178
230
 
179
 
.. note:: An additional option is supported for bzr. **'bzr-init'**
180
 
          defines the way the bzr branch
181
 
          is initialized for addons or server declared with a bzr
182
 
          repository path.
183
 
 
184
 
          Possible values:
185
 
 
186
 
          branch (default)
187
 
            Working copy initialized with the command
188
 
            ``bzr branch url ...``
189
 
          stacked-branch
190
 
           Working copy initialized with the command
191
 
           ``bzr branch --stacked url ...``
192
 
 
193
 
          lightweight-checkout
194
 
            Working copy initialized with the command
195
 
            ``bzr checkout --lightweight url ...``
 
231
The ``subdir`` addons option
 
232
````````````````````````````
 
233
 
 
234
The ``subdir`` option, if used, makes the recipe use the given
 
235
subdirectory of the repository as the addons directory.
 
236
A very common example is the line for standard web addons from bzr::
 
237
 
 
238
   bzr lp:openerp-web/7.0 openerp-web last:1 subdir=addons
 
239
 
 
240
The ``bzr-init`` addons option
 
241
``````````````````````````````
 
242
**'bzr-init'** defines the way the bzr branch
 
243
is initialized for addons or server declared with a bzr
 
244
repository path.
 
245
 
 
246
.. note:: new in version 1.7.0
 
247
 
 
248
Possible values:
 
249
 
 
250
:branch (default):  Working copy initialized with the command
 
251
                    ``bzr branch url ...``
 
252
 
 
253
:stacked-branch:  Working copy initialized with the command
 
254
                  ``bzr branch --stacked url ...``
 
255
:lightweight-checkout: Working copy initialized with the command
 
256
                       ``bzr checkout --lightweight url ...``
 
257
 
 
258
.. _eggs:
 
259
 
 
260
eggs
 
261
----
 
262
This option behaves like the identically named one of the most common
 
263
`zc.recipe.egg <https://pypi.python.org/pypi/zc.recipe.egg>`_.
 
264
 
 
265
Starting from version 0.16 of the recipe, you don't need to put anything in
 
266
this option by default: the recipe is supposed to add all needed
 
267
dependencies for OpenERP by itself, but you have to specify additional
 
268
eggs needed by addons, or just useful ones::
 
269
 
 
270
    eggs = ipython
 
271
           python-ldap
 
272
           openobject-library
 
273
 
 
274
.. _revisions:
196
275
 
197
276
revisions
198
277
---------
199
278
 
200
279
This option allows to further precise what has been specified through
201
 
the  ``addons`` and ``version`` options by fixing VCS revisions.
 
280
the  :ref:`addons` and :ref:`version` options by fixing VCS revisions.
202
281
 
203
 
The main use-case it to apply it in an extension buildout
204
 
configuration file::
 
282
The main use-case it to apply it in an :ref:`extension buildout
 
283
configuration file <extends>`::
205
284
 
206
285
   [buildout]
207
286
   extends = base.cfg
211
290
               addons-openerp 7109
212
291
 
213
292
As you can see in that example, the first token is the target
214
 
filesystem path, as in the ``addons`` option, the second one is the
 
293
filesystem path, as in the :ref:`addons` option, the second one is the
215
294
revision, except in the case of the main software (if VCS based), for
216
295
which there's no filesystem path.
217
296
 
223
302
* freezing satisfactory revisions in a release process (the recipe can
224
303
  do that automatically for you, see ``freeze-to`` option below).
225
304
 
 
305
.. _clean:
 
306
 
226
307
clean
227
308
-----
228
309
 
229
310
If set to true, this option will clean remove python object files from
230
 
the main server part and addons before any update or install.
 
311
the main server part and addons before any update or install, and
 
312
perform relevant VCS idea of "clean, purge".
 
313
 
 
314
.. warning:: developers can lose their uncommitted work with this option.
 
315
 
 
316
             This option is not meant for developer setups, rather for
 
317
             deployment and continuous integration. To avoid making a
 
318
             dedicated buildout configuration for you CI bot, just add
 
319
             it on the command-line.
231
320
 
232
321
Note that tarball downloads get re-extracted afresh in any case.
233
322
 
234
 
openerp_scripts
235
 
---------------
236
 
 
237
 
Introduction and use-cases
238
 
``````````````````````````
239
 
This option lets you install console scripts provided by any of the loaded eggs,
240
 
so that they can access to OpenERP internals and load databases.
241
 
Some interesting use-cases:
242
 
 
243
 
* specific batch jobs
244
 
* introspection tools
245
 
* general-purposes test launchers that don't have any knowledge of
246
 
  OpenERP specifics
247
 
* actually, the main startup scripts themselves (with a default
248
 
  configuration, of course)
249
 
 
250
 
Usage
251
 
`````
252
 
This multiline option is similar to the classical ``scripts`` options
253
 
of ``zc.recipe.eggs:scripts``. It lets you ask for installation of
254
 
console scripts provided by the various Python distribution involved
255
 
in the buildout part (including OpenERP itself).
256
 
 
257
 
The built console scripts can import all the involved Python
258
 
distributions, and have access to a ``session`` object, to issue
259
 
OpenERP native calls (see
260
 
``interpreter_name`` option below for details on how to use it).
261
 
 
262
 
One has to register exactly one console script per line.
263
 
 
264
 
As it is the case with ``scripts``, one actually specifies the name of the
265
 
entry point to use (we are all used to that entry point being the name
266
 
of the resulting script, because that's what ``setup.py install`` does).
267
 
 
268
 
Suppose there is a distribution ``my.package`` with the following lines in
269
 
its ``setup.py``::
270
 
 
271
 
      entry_points="""
272
 
 
273
 
      [console_scripts]
274
 
      my = my.package.main:run
275
 
      """
276
 
 
277
 
Now the following configuration extract builds a script called
278
 
``my_openerp1``, that can access ``session``::
279
 
 
280
 
  [openerp1]
281
 
  (...)
282
 
  openerp_scripts = my
283
 
 
284
 
To control the script name, just do, e.g,::
285
 
 
286
 
  [openerp1]
287
 
  (...)
288
 
  openerp_scripts = my=my_script
289
 
 
290
 
This will build it as ``bin/my_script``.
291
 
 
292
 
Command-line options and test launchers
293
 
```````````````````````````````````````
294
 
 
295
 
If ``my.package`` is meant to do OpenERP heavy-lifting, then surely it
296
 
will provide a powerful command-line parsing. e.g., to let the end user chose
297
 
the database on which to work, etc.
298
 
 
299
 
Sometimes, however, the script itself has no knowledge of OpenERP at
300
 
all, but still must run after a database has been fully initialized.
301
 
The main use case for this is test launchers, such as
302
 
`nose <https://nose.readthedocs.org/en/latest/>`_ or simply ``unit2``.
303
 
For these, the recipe has a facility to rewrap the script and add some further
304
 
command-line options.
305
 
 
306
 
In this example, we build ``unit2``, the launcher that comes with
307
 
``unittest2``, and wrap it to add the database option::
308
 
 
309
 
  [openerp]
310
 
  (...)
311
 
  openerp_scripts = unit2 command-line-options=-d
312
 
 
313
 
You may then run it this way::
314
 
 
315
 
   bin/unit2_openerp -d unit-tests-db -- discover some/addon
316
 
 
317
 
Notice how ``--`` is used to separate the ``-d`` or
318
 
any recipe-related options from the options expected by the script itself.
319
 
 
320
 
If one wishes to run the tests with ``nose``, one has further to
321
 
require it. In the following example, we also ask for the ``coverage``
322
 
package::
323
 
 
324
 
  [openerp]
325
 
  (...)
326
 
  eggs = nose
327
 
         coverage
328
 
  openerp_scripts = nosetests command-line-options=-d
329
 
 
330
 
Here's our test run with coverage and pdb post-mortem::
331
 
 
332
 
  bin/nosetests-openerp -d unit-tests-db -- --nologcapture \
333
 
           --with-coverage --pdb \
334
 
           some/addon/tests/test_one.py
335
 
 
336
 
Main startup scripts
337
 
````````````````````
338
 
The recipe will in all cases build OpenERP startup scripts, according to other
339
 
configuration options (gunicorn, tests etc.). These are
340
 
actually special cases of the scripts controlled via ``openerp_scripts``.
341
 
 
342
 
This allows you (for now) to control the names. For instance, to
343
 
replace ``bin/start_openerp`` with ``bin/oerp``, just do::
344
 
 
345
 
  [openerp]
346
 
  (...)
347
 
  openerp_scripts = openerp_starter=oerp
348
 
 
349
 
Here's the list of currently available internal entry points. For
350
 
these, the ``command-line-options`` modifier has no effect.
351
 
 
352
 
:openerp_starter: main OpenERP startup script (dynamically added
353
 
                  behing the scenes by the recipe)
354
 
:openerp_tester: uniform script to start OpenERP, launch all tests and
355
 
                 exit. This can be achieved with the main startup
356
 
                 scripts, but options differ among OpenERP versions.
357
 
                 (also dynamically added behind the scenes).
358
 
:openerp_cron_worker: entry point for the cron worker script that gets
359
 
                      built for gunicorn setups.
360
 
:oe: entry point declared by ``openerp-command`` and used by the recipe.
361
 
:gunicorn: entry point declared by ``gunicorn`` and used by the recipe.
 
323
.. _openerp_options:
 
324
 
 
325
OpenERP options
 
326
~~~~~~~~~~~~~~~
 
327
 
 
328
With the OpenERP buildout recipes, OpenERP options are managed
 
329
directly from the buildout file (usually
 
330
``buildout.cfg``) from the part.
 
331
 
 
332
The OpenERP configuration files are generated by OpenERP itself in the directory
 
333
specified by ``etc-directory``, which defaults to the `etc` directory under your
 
334
buildout directory.
 
335
 
 
336
The settings of the OpenERP configuration files are specified using a
 
337
dotted notation in which the fist segment is the name of the
 
338
corresponding section of the OpenERP config file and the second is the
 
339
option name.
 
340
 
 
341
The specified options will just overwrite the existing
 
342
options in the corresponding config files. You don't have to replicate all the
 
343
options in your section of the buildout file.  If a setting or a section does
 
344
not natively exist in the openerp config file, it can be created from there for
 
345
your application.
 
346
 
 
347
For example you can specify the xmlrpc port for the server or
 
348
even an additional option that does not exist in the default config file::
 
349
 
 
350
  options.xmlrpc_port = 8069
 
351
  options.additional_option = "foobar"
 
352
 
 
353
It will end-up in the server configuration as::
 
354
 
 
355
  [options]
 
356
  xmlrpc_port = 8069
 
357
  additional_option = "foobar"
 
358
 
 
359
For the web client you can specify the port and company url with::
 
360
 
 
361
  global.server.socket_port = 8080
 
362
  openerp-web.company.url = 'http://anybox.fr'
 
363
 
 
364
It will modify the corresponding web client config::
 
365
 
 
366
  [global]
 
367
  server.socket_port = 8080
 
368
 
 
369
  [openerp-web]
 
370
  company.url = 'http://anybox.fr'
 
371
 
 
372
.. note:: Buildout :ref:`configuration inheritance <extends>` is
 
373
          especially useful to manage the separation between a
 
374
          reusable buildout configuration and local settings.
 
375
 
 
376
.. note:: Note that for security reasons, the superadmin password is not set by
 
377
    default. If you want databases to be manageable through the UI,
 
378
    you may either explicitely set that password in the buildout part
 
379
    configuration or even set it temporarily in the
 
380
    ``etc/openerp.conf`` file.
 
381
 
 
382
 
 
383
Options for executables generation and serving
 
384
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
385
 
 
386
.. _script_name:
362
387
 
363
388
script_name
364
389
-----------
365
390
 
366
391
.. warning:: as of version 1.7.0, this option is deprecated because of its
367
 
             redundancy with ``openerp_scripts``.
368
 
 
369
 
OpenERP startup scripts are created in the `bin` directory. By default the name is:
370
 
start_<part_name>, so you can have several startup scripts for each part if you
371
 
configure several OpenERP servers or clients. You can pass additional typical
 
392
             redundancy with :ref:`openerp_scripts`.
 
393
 
 
394
OpenERP startup scripts are created in the `bin` directory. By default
 
395
the name is ``start_<part_name>``, so you can have several startup
 
396
scripts for each part if you configure several OpenERP servers or clients.
 
397
 
 
398
You can pass additional typical
372
399
arguments to the server via the startup script, such as -i or -u options.
373
400
 
374
401
You can choose another name for the script by using the *script_name*
375
402
option ::
376
403
 
377
 
    script_name = start_erp  
378
 
 
379
 
interpreter_name
380
 
----------------
381
 
 
382
 
The recipe will automatically create a python interpreter with a
383
 
``session`` object that can bootstrap OpenERP with a database right
384
 
away. You can use that for interactive sessions or to launch a script::
385
 
 
386
 
    $ bin/python_openerp
387
 
    To start the OpenERP working session, just do:
388
 
       session.open()
389
 
    or
390
 
       session.open(db=DATABASE_NAME)
391
 
    Then you can issue commands such as
392
 
       session.registry('res.users').browse(session.cr, 1, 1)
393
 
 
394
 
    >>>
395
 
 
396
 
The interpreter name is  ``python_<part_name>`` by default; but it can
397
 
be explicitely set like this::
398
 
 
399
 
    interpreter_name = my_py
400
 
 
401
 
If you want *not* to have the interpreter, juste do
402
 
 
403
 
    interpreter_name =
404
 
 
405
 
The bootstrapping facility may also be used within a script installed
406
 
by an egg; just insert this in your code to get the session object as
407
 
if you were in the interpreter::
408
 
 
409
 
    from anybox.recipe.openerp.startup import Session
410
 
    session = Session()
411
 
 
412
 
.. note:: this facility is new in version 1.6.0, and tested with
413
 
          OpenERP 7 only for now.
414
 
 
415
 
startup_delay
416
 
-------------
417
 
 
418
 
Specifies a delay in seconds to wait before actually launching OpenERP. This
419
 
option was a preliminary hack to support both gunicorn instance and a legacy
420
 
instance.  The Gunicorn startup script (see below) itself is not affected by
421
 
this setting ::
422
 
 
423
 
    startup_delay = 3
424
 
 
425
 
with_devtools
426
 
-------------
427
 
Allows to load development and install useful devlopment and testing
428
 
tools, notably the following scripts:
429
 
 
430
 
* ``test_openerp``: a uniform test launcher for all supported
431
 
  versions. See test_script_name option below for details.
432
 
* ``openerp_command``: see openerp_command_name option below for
433
 
  details. Not installed for OpenERP major versions less than or equal to 6.1.
434
 
 
435
 
This option is False by default, hence it's activated this way::
436
 
 
437
 
    with_devtools = true
438
 
 
439
 
It will also add some dependencies that are typical to development
440
 
setups (tests related packages etc.) and automatically load where
441
 
needed helpers, such as `anybox.testing.datetime
442
 
<http://pypi.python.org/pypi/anybox.testing.datetime>`_ (allows to
443
 
cheat with system time).
444
 
 
445
 
test_script_name
446
 
----------------
447
 
.. warning:: as of version 1.7.0, this option is deprecated because of its
448
 
             redundancy with ``openerp_scripts``.
449
 
 
450
 
If the ``with_devtools`` is set to True, the recipe will create a
451
 
test script, which is named by default ``test_<part_name>``. You may
452
 
override the name in the configuration as in the following example::
453
 
 
454
 
  test_script_name = test_erp
455
 
 
456
 
The test script takes the same arguments as the regular startup
457
 
script::
458
 
 
459
 
  bin/test_openerp --help
460
 
  bin/test_openerp -d test_db -i purchase,sale
461
 
 
462
 
At the time of this writing, all this script does compared to the
463
 
regular startup script is to bring uniformity across OpenERP versions
464
 
by tweaking options internally.
465
 
 
466
 
base_url
467
 
--------
468
 
 
469
 
URL from which to download official and nightly versions
470
 
(assuming the archive filenames are constistent with those in
471
 
OpenERP download server). This is a basic mirroring capability::
472
 
 
473
 
    base_url = http://download.example.com/openerp/
474
 
 
475
 
openerp-downloads-directory
476
 
---------------------------
477
 
 
478
 
Allows to share OpenERP downloads among several buildouts. You should put this
479
 
option in your ``~/.buildout/default.cfg`` file.  It specifies the destination
480
 
download directory for OpenERP archives. The path may be absolute or relative
481
 
to the buildout directory.
482
 
 
483
 
Example::
484
 
 
485
 
    [buildout]
486
 
    openerp-downloads-directory = /home/user/.buildout/openerp-downloads
 
404
    script_name = start_erp
 
405
 
 
406
 
 
407
.. _openerp_scripts:
 
408
 
 
409
openerp_scripts
 
410
---------------
 
411
This option lets you install console scripts provided by any of the loaded eggs,
 
412
so that they can access to OpenERP internals and load databases.
 
413
 
 
414
.. note:: new in version 1.7.0
 
415
 
 
416
Here we describe the format of the option only.
 
417
For explanation about what it means and how to use it, please refer to
 
418
:doc:`/scripts`.
 
419
 
 
420
The option is multiline. Each line specifies exactly one
 
421
script, and must respect the following format:
 
422
 
 
423
  ``ENTRY_POINT_NAME[=WISHED_SCRIPT_NAME] [MODIFIER [MODIFIER […]]]``
 
424
 
 
425
Each modifier takes the ``MODIFIER_NAME=MODIFIER_VALUE`` form.
 
426
No whitespace is allowed in modifiers, entry point, nor produced script names.
 
427
 
 
428
Here's the list of currently available modifiers, with links inside :doc:`the
 
429
dedicated chapter about OpenERP scripts </scripts>`).
 
430
 
 
431
:command-line-options: :ref:`command_line_options`
 
432
:arguments: :ref:`arguments_session`
 
433
 
 
434
Full example::
 
435
 
 
436
  openerp_scripts = my_script arguments=session
 
437
                    my_other_script=actual-script-name arguments=3,session
 
438
                    nosetests=nosetests command-line-options=-d
 
439
 
 
440
 
 
441
.. _upgrade_script_name:
 
442
 
 
443
upgrade_script_name
 
444
-------------------
 
445
 
 
446
This option lets you specify the wished name for the upgrade script.
 
447
The default value is ``upgrade_<part_name>``.
 
448
 
 
449
.. note:: new in version 1.8.0.
 
450
 
 
451
          We are actually not sure to keep that option, since it's
 
452
          redundant with :ref:`openerp_scripts`.
 
453
 
 
454
 
 
455
.. _upgrade_script:
 
456
 
 
457
upgrade_script
 
458
--------------
 
459
 
 
460
.. note:: new in version 1.8.0
 
461
 
 
462
This option lets you specify a source (``.py``) file and a callable
 
463
defined in that file to perform database upgrades. The default value
 
464
is::
 
465
 
 
466
  upgrade_script = upgrade.py run
 
467
 
 
468
If the specified source file doest not exist, the recipe will
 
469
initialize it with a simple and meaningful sample content, consistent
 
470
with the default value above.
 
471
 
 
472
If you want *not* to have an upgrade script, just override this option
 
473
with a blank value::
 
474
 
 
475
  upgrade_script =
 
476
 
 
477
See the full :ref:`upgrade_scripts` documentation to learn more
 
478
about upgrade scripts.
 
479
 
 
480
.. note:: new in version 1.8.0
 
481
 
 
482
 
 
483
.. _gunicorn:
487
484
 
488
485
gunicorn
489
486
--------
490
487
 
491
 
Gunicorn integration is only supported on OpenERP >= 6.1.
 
488
Gunicorn integration is only supported on OpenERP ≥ 6.1.
492
489
Any value of this option makes the recipe generate a script to start
493
490
OpenERP with Gunicorn and (*new in version 1.1*) a dedicated script to
494
491
handle cron jobs.
495
492
 
496
493
For OpenERP 6.1, the only accepted values are ``direct`` and
497
 
``proxied``. Any value is suitable for OpenERP >= 7
 
494
``proxied``. Any value is suitable for OpenERP ≥ 7
498
495
 
499
496
Proxied mode
500
497
````````````
503
500
 
504
501
    gunicorn = proxied
505
502
 
506
 
This behaviour has been kept for OpenERP >= 7 to keep
 
503
This behaviour has been kept for OpenERP ≥ 7 to keep
507
504
backwards compatibility, but the option is now superseded by the
508
505
general ``proxy_mode`` option of the server. In the buildout context,
509
506
that'd be::
552
549
allows for graceful restarts (use this for minor changes only).
553
550
 
554
551
 
 
552
.. _openerp_command_name:
 
553
 
555
554
openerp_command_name
556
555
--------------------
557
 
.. warning:: as of version 1.7.0, this option is deprecated, check
558
 
   ``openerp_scripts`` for more details.
 
556
.. warning:: as of version 1.7.0, this option is deprecated because of
 
557
             its redundancy with :ref:`openerp_scripts`.
559
558
 
560
559
OpenERP Command Line Tools (openerp-command for short) is an
561
560
alternative set of command-line tools that may someday subsede the
562
561
current monolithic startup script. Currently experimental, but
563
562
already very useful in development mode.
564
563
 
565
 
It is currently enabled if the ``with_devtools`` option is on.
 
564
It is currently enabled if the :ref:`with_devtools` option is on.
566
565
 
567
566
This works by requiring the ``openerp-command`` python
568
 
distribution, which is not on PyPI as of this writting. You may want
569
 
to use the ``vcsdevelop`` extension to get it from Launchpad::
570
 
 
571
 
  [buildout]
572
 
  extensions = gp.vcsdevelop
573
 
  vcs-extend-develop = bzr+http://bazaar.launchpad.net/openerp/openerp-command#egg=openerp-command
 
567
distribution, which is not on PyPI as of this writting, but comes
 
568
bundled with the current OpenERP trunk (believed to be the future
 
569
OpenERP 8).
574
570
 
575
571
As for other scripts, you can control its name of the produced script, e.g::
576
572
 
580
576
``oe`` is the classical name for this script outside of the realm of
581
577
this buildout recipe.
582
578
 
 
579
.. note:: ``openerp-command`` has first been introduced as a separate
 
580
          project while OpenERP 7.0 was in development stage. People
 
581
          wanting to use it with OpenERP 7.0 can still grab it from
 
582
          Launchpad with the ``gp.vcsdevelop`` extension::
 
583
 
 
584
            [buildout]
 
585
            extensions = gp.vcsdevelop
 
586
            vcs-extend-develop = bzr+http://bazaar.launchpad.net/openerp/openerp-command@419#egg=openerp-command
 
587
 
 
588
          The latest Launchpad revision is actually the final removal,
 
589
          done at the time where it's been included in
 
590
          ``lp:openobject-server``.
 
591
 
 
592
 
583
593
.. warning::
584
594
 
585
 
  Do not use to launch production servers, especially in an automatic
586
 
  way, openerp-command is really unstable and that may damage your
587
 
  installation.
 
595
  On OpenERP 7, do not use to launch production servers, especially in
 
596
  an automatic way, ``openerp-command`` is really unstable and that
 
597
  may damage your installation.
 
598
 
 
599
 
 
600
 
 
601
scripts
 
602
-------
 
603
.. note:: This option is useful for general purpose scripts
 
604
          only. For scripts related to OpenERP, see
 
605
          :doc:`/scripts`, and the :ref:`openerp_scripts` option.
 
606
 
 
607
This option controls the generation of console scripts declared by the
 
608
various involved Python distributions (either directly required with
 
609
the :ref:`eggs` option, or by dependency).
 
610
 
 
611
By default, no such script is generated, but you may specify some
 
612
according to your needs, with the same semantics as in ``zc.recipe.egg``.
 
613
 
 
614
        scripts = change_tz
 
615
 
 
616
In the current state, beware to *not* require the same script in different
 
617
parts or rename them. See
 
618
https://bugs.launchpad.net/anybox.recipe.openerp/+bug/1020967 for
 
619
details.
 
620
 
 
621
 
 
622
.. _startup_delay:
 
623
 
 
624
startup_delay
 
625
-------------
 
626
 
 
627
Specifies a delay in seconds to wait before actually launching OpenERP. This
 
628
option was a preliminary hack to support both gunicorn instance and a legacy
 
629
instance.  The Gunicorn startup script (see below) itself is not affected by
 
630
this setting ::
 
631
 
 
632
    startup_delay = 3
 
633
 
 
634
Options for development, QA and introspection
 
635
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
636
 
 
637
.. _with_devtools:
 
638
 
 
639
with_devtools
 
640
-------------
 
641
Allows to load development and install useful devlopment and testing
 
642
tools, notably the following scripts:
 
643
 
 
644
* ``test_openerp``: a uniform test launcher for all supported
 
645
  versions. See test_script_name option below for details.
 
646
* ``openerp_command``: see openerp_command_name option below for
 
647
  details. Not installed for OpenERP major versions less than or equal to 6.1.
 
648
 
 
649
This option is False by default, hence it's activated this way::
 
650
 
 
651
    with_devtools = true
 
652
 
 
653
It will also add some dependencies that are typical to development
 
654
setups (tests related packages etc.) and automatically load where
 
655
needed helpers, such as `anybox.testing.datetime
 
656
<http://pypi.python.org/pypi/anybox.testing.datetime>`_ (allows to
 
657
cheat with system time).
 
658
 
 
659
 
 
660
.. _test_script_name:
 
661
 
 
662
test_script_name
 
663
----------------
 
664
.. warning:: as of version 1.7.0, this option is deprecated because of its
 
665
             redundancy with :ref:`openerp_scripts`.
 
666
 
 
667
If the ``with_devtools`` is set to True, the recipe will create a
 
668
test script, which is named by default ``test_<part_name>``. You may
 
669
override the name in the configuration as in the following example::
 
670
 
 
671
  test_script_name = test_erp
 
672
 
 
673
The test script takes the same arguments as the regular startup
 
674
script::
 
675
 
 
676
  bin/test_openerp --help
 
677
  bin/test_openerp -d test_db -i purchase,sale
 
678
 
 
679
At the time of this writing, all this script does compared to the
 
680
regular startup script is to bring uniformity across OpenERP versions
 
681
by tweaking options internally.
 
682
 
 
683
*As of version 1.8.2*, the ``--install-all`` additional option will be
 
684
expanded on-the-fly as ``-i`` on all available modules (don't confuse
 
685
with ``-i all``: the latter is equivalent to ``-i base``).
 
686
 
 
687
 
 
688
.. _interpreter_name:
 
689
 
 
690
interpreter_name
 
691
----------------
 
692
 
 
693
The recipe will automatically create a python interpreter with a
 
694
``session`` object that can bootstrap OpenERP with a database right
 
695
away. You can use that for interactive sessions or to launch a script::
 
696
 
 
697
    $ bin/python_openerp
 
698
    To start the OpenERP working session, just do:
 
699
       session.open()
 
700
    or
 
701
       session.open(db=DATABASE_NAME)
 
702
    Then you can issue commands such as
 
703
       session.registry('res.users').browse(session.cr, 1, 1)
 
704
 
 
705
    >>>
 
706
 
 
707
The interpreter name is  ``python_<part_name>`` by default; but it can
 
708
be explicitely set like this::
 
709
 
 
710
    interpreter_name = my_py
 
711
 
 
712
If you want *not* to have the interpreter, juste do
 
713
 
 
714
    interpreter_name =
 
715
 
 
716
If you want to wrap a python script with such session objects, read
 
717
:doc:`/scripts` and especially :ref:`arguments_session`.
 
718
See also :ref:`openerp_scripts`.
 
719
 
 
720
.. note:: this facility is new in version 1.6.0, and tested with
 
721
          OpenERP ≥ 6.1 only for now.
 
722
 
 
723
 
 
724
interpreter
 
725
-----------
 
726
With the ``gtkclient`` and ``webclient`` recipes,
 
727
this behauves like the `interpreter` option of `zc.recipe.egg`: it
 
728
gives you a Python interpreter in the ``bin`` subdirectory of the buildout::
 
729
 
 
730
    interpreter = erp_python
 
731
 
 
732
With the ``server`` recipe, the ``interpreter`` option will be ignored,
 
733
because this recipe always creates an interpreter with preloaded objects to
 
734
bootstrap openerp, and these depend on the configuration.
 
735
Check :ref:`interpreter_name` for more details.
 
736
 
 
737
 
 
738
 
 
739
 
 
740
Options for download and caching strategies
 
741
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
742
 
 
743
Let us start by listing a few global buildout options (to be put in
 
744
the ``[buildout]`` section), whose scope is much larger than the
 
745
OpenERP recipe.
 
746
 
 
747
:eggs-directory: control where eggs are stored after download and/or
 
748
                 build and reciprocally acts as a cache.
 
749
:index: specifies where to get informations about distributions not found in
 
750
        ``eggs-directory``.
 
751
:find-links: direct URLs to look for distributions
 
752
:allow-hosts: white list of URL patterns allowed for distributions
 
753
              download. Great to exclude the numerous useless sites
 
754
              that setuptools may want to crawl and which tend to
 
755
              break each time a new version gets referenced on PyPI.
 
756
 
 
757
The OpenERP recipes define a few more.
 
758
 
 
759
 
 
760
.. _base_url:
 
761
 
 
762
base_url
 
763
--------
 
764
This option is local to the *part*.
 
765
 
 
766
URL from which to download official and nightly versions
 
767
(assuming the archive filenames are constistent with those in
 
768
OpenERP download server). This is a basic mirroring capability::
 
769
 
 
770
    base_url = http://download.example.com/openerp/
 
771
 
 
772
 
 
773
.. _openerp-downloads-directory:
 
774
 
 
775
openerp-downloads-directory
 
776
---------------------------
 
777
This is an option for the ``[buildout]`` section
 
778
 
 
779
Allows to share OpenERP downloads among several buildouts. You should put this
 
780
option in your ``~/.buildout/default.cfg`` file.  It specifies the destination
 
781
download directory for OpenERP archives. The path may be absolute or relative
 
782
to the buildout directory.
 
783
 
 
784
Example::
 
785
 
 
786
    [buildout]
 
787
    openerp-downloads-directory = /home/user/.buildout/openerp-downloads
 
788
 
 
789
 
 
790
 
 
791
Options for release and packaging
 
792
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
793
 
 
794
.. note:: release and packaging should be provided by dedicated
 
795
          executables, not by options. These options should disappear
 
796
          at some point between 1.8 and 1.9 versions.
 
797
 
 
798
.. _freeze-to:
588
799
 
589
800
freeze-to
590
801
---------
613
824
    bin/buildout -o openerp-server-1:freeze-to=frozen.cfg
614
825
 
615
826
This produces a buildout configuration file named ``frozen.cfg``,
616
 
with notably an ``openerp-server-1`` part having a ``revisions`` option that
 
827
with notably an ``openerp-server-1`` part having a :ref:`revisions` option that
617
828
freezes everything.
618
829
 
619
830
For configurations with several openerp related parts, you can freeze
641
852
.. warning:: currently ``freeze-to`` cannot fix eggs versions related
642
853
             to non-openerp parts.
643
854
 
 
855
.. _freeze-allow-picked-versions:
 
856
 
644
857
freeze-allow-picked-versions
645
858
----------------------------
646
859
 
647
 
This option is to be used in conjunction with ``freeze-to``. If set to
 
860
This option is to be used in conjunction with :ref:`freeze-to`. If set to
648
861
``False``, it will add ``allow-picked-versions = false``
649
862
for ``zc.buildout`` versions that support this flag.
650
863
 
651
864
.. warning:: in the current state of things, this can cause problems
652
 
             if you have non-openerp parts (see warning in ``freeze-to``
653
 
             documentation).
 
865
             if you have non-openerp parts (see the various warnings
 
866
             in :ref:`freeze-to`)
654
867
 
 
868
.. _extract-downloads-to:
655
869
 
656
870
extract-downloads-to
657
871
--------------------
658
872
 
659
 
Following the same kind of logic as ``freeze-to``, this option allows
 
873
Following the same kind of logic as :ref:`freeze-to`, this option allows
660
874
to turn a buildout that aggregates from various remote sources
661
875
(tarball downloads, VCSes) into a self-contained buildout archive
662
876
directory that can be packed for easy distribution.
685
899
or further extended for system-dependent options such as port, db
686
900
connection, etc.
687
901
 
688
 
The ``extract-downloads-to`` options can be used for several parts
689
 
with the same target directory (same as ``freeze-to``).
 
902
The ``extract-downloads-to`` option can be used for several parts
 
903
with the same target directory (same as :ref:`freeze-to`).
690
904
 
691
905
Furthermore, a default ``freeze-to`` is issued, producing a buildout
692
906
configuration called ``extracted_from.cfg`` in the target directory,
698
912
same rules with respect to uncommitted changes.
699
913
 
700
914
Python distributions managed with ``gp.vcsdevelop`` are taken into account.
701
 
 
702
 
 
703
 
OpenERP options
704
 
---------------
705
 
 
706
 
You can define OpenERP options directly from the buildout file (usually
707
 
``buildout.cfg``) in the recipe section.
708
 
The OpenERP configuration files are generated by OpenERP itself in the directory
709
 
specified by ``etc-directory`` which defaults to the `etc` directory under your
710
 
buildout directory.
711
 
The settings of the OpenERP configuration files can be controlled using a
712
 
dotted notation prefixed by the name of the corresponding section of the
713
 
OpenERP config file. The specified options will just overwrite the existing
714
 
options in the corresponding config files. You don't have to replicate all the
715
 
options in your section of the buildout file.  If a setting or a section does
716
 
not natively exist in the openerp config file, it can be created from there for
717
 
your application.
718
 
 
719
 
For example you can specify the xmlrpc port for the server or
720
 
even an additional option that does not exist in the default config file::
721
 
 
722
 
  options.xmlrpc_port = 8069
723
 
  options.additional_option = "foobar"
724
 
 
725
 
It will end-up in the server config as::
726
 
 
727
 
  [options]
728
 
  xmlrpc_port = 8069
729
 
  additional_option = "foobar"
730
 
 
731
 
For the web client you can specify the company url with::
732
 
 
733
 
  global.server.socket_port = 8080
734
 
  openerp-web.company.url = 'http://anybox.fr'
735
 
 
736
 
It will modify the corresponding web client config::
737
 
 
738
 
  [global]
739
 
  server.socket_port = 8080
740
 
 
741
 
  [openerp-web]
742
 
  company.url = 'http://anybox.fr'
743
 
 
744
 
 
745
 
.. note:: Note that for security reason, the superadmin password is not set by
746
 
    default. If you want to create a database you should temporary set it manually
747
 
    in the etc/openerp.conf file
748
 
 
749
 
 
750
 
 
751
 
.. _howto:
752
 
 
753
 
How to create and bootstrap a buildout
754
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
755
 
 
756
 
To create a buildout and run the build, you just need **1 file** and **2 commands**:
757
 
 
758
 
- Create a single ``buildout.cfg`` file.
759
 
- Be sure you installed all your build dependencies
760
 
- Bootstrap the buildout with: ``python bootstrap.py``
761
 
- Run the build with: ``bin/buildout``
762
 
 
763
 
The same with more details below :
764
 
 
765
 
Creating the buildout
766
 
---------------------
767
 
 
768
 
Create a ``buildout.cfg`` file in an empty directory, containing the
769
 
configuration of the `example 6.1`_ section.
770
 
 
771
 
.. _dependencies:
772
 
 
773
 
Installing build dependencies
774
 
-----------------------------
775
 
 
776
 
You basically need typical development tools needed to build all the Python
777
 
dependency eggs of OpenERP. You can do this by yourself with your system or
778
 
Linux distribution.
779
 
 
780
 
Or if you're using a Debian system, we provide a single dependency package you
781
 
can use to install all dependencies in one shot:
782
 
 
783
 
Add the following line in your ``/etc/apt/sources.list``::
784
 
 
785
 
  deb http://apt.anybox.fr/openerp common main
786
 
 
787
 
Install the dependency package::
788
 
 
789
 
  $ sudo aptitude update 
790
 
  $ sudo aptitude install openerp-server-system-build-deps
791
 
 
792
 
You can uninstall this package with `aptitude` after the build to
793
 
automatically remove all un-needed dependencies, but you need to
794
 
install *run dependencies* before that ::
795
 
 
796
 
  $ sudo aptitude install openerp-server-system-run-deps
797
 
  $ sudo aptitude remove openerp-server-system-build-deps
798
 
 
799
 
Please note that these package will have your system install the
800
 
*client* part of PostgreSQL software only. If you want a
801
 
PostgreSQL server on the same host, that's not in the recipe scope,
802
 
just install it as well.
803
 
 
804
 
Bootstrapping the buildout
805
 
--------------------------
806
 
 
807
 
Bootstrapping the buildout consists in creating the basic structure of the buildout, and installing buildout itself in the directory.
808
 
 
809
 
The easiest and recommended way to bootstrap is to use a ``bootstrap.py`` script::
810
 
 
811
 
  $ wget https://raw.github.com/buildout/buildout/master/bootstrap/bootstrap.py
812
 
  $ python bootstrap.py
813
 
 
814
 
As an alternative and more complicated solution, you may also bootstrap by
815
 
creating a virtualenv, installing zc.buildout, then run the bootstrap::
816
 
 
817
 
  $ virtualenv sandbox
818
 
  $ sandbox/bin/pip install zc.buildout
819
 
  $ sandbox/bin/buildout bootstrap
820
 
 
821
 
Running the build
822
 
-----------------
823
 
 
824
 
Just run ::
825
 
 
826
 
  $ bin/buildout
827
 
 
828
 
Starting OpenERP
829
 
----------------
830
 
 
831
 
Just run ::
832
 
 
833
 
  $ bin/start_openerp
834
 
 
835
 
 
836
 
.. _example 6.1:
837
 
 
838
 
Example OpenERP 6.1 buildout
839
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
840
 
 
841
 
Here is a very simple example for a latest OpenERP 6.1 nightly and a
842
 
custom addon hosted on Bitbucket:
843
 
 
844
 
::
845
 
 
846
 
    [buildout]
847
 
    parts = openerp 
848
 
    versions = versions
849
 
    find-links = http://download.gna.org/pychart/
850
 
    
851
 
    [openerp]
852
 
    recipe = anybox.recipe.openerp:server
853
 
    # replace '6.1' with 'trunk' to get a 7.0 current nightly:
854
 
    version = nightly 6.1 latest
855
 
    addons = hg https://bitbucket.org/anybox/anytracker addons-at default
856
 
 
857
 
    [versions]
858
 
    MarkupSafe = 0.15
859
 
    Pillow = 1.7.7
860
 
    PyXML = 0.8.4
861
 
    babel = 0.9.6
862
 
    feedparser = 5.1.1
863
 
    gdata = 2.0.16
864
 
    lxml = 2.3.3
865
 
    mako = 0.6.2
866
 
    psycopg2 = 2.4.4
867
 
    pychart = 1.39
868
 
    pydot = 1.0.28
869
 
    pyparsing = 1.5.6
870
 
    python-dateutil = 1.5
871
 
    python-ldap = 2.4.9
872
 
    python-openid = 2.2.5
873
 
    pytz = 2012b
874
 
    pywebdav = 0.9.4.1
875
 
    pyyaml = 3.10
876
 
    reportlab = 2.5
877
 
    simplejson = 2.4.0
878
 
    vatnumber = 1.0
879
 
    vobject = 0.8.1c
880
 
    werkzeug = 0.8.3
881
 
    xlwt = 0.7.3
882
 
    zc.buildout = 1.5.2
883
 
    zc.recipe.egg = 1.3.2
884
 
    zsi = 2.0-rc3
885
 
 
886
 
 
887
 
.. note:: with OpenERP 6.1 the web client is natively included in the server as a
888
 
    simple module. In that case you don't need to write a separate part for the web
889
 
    client, unless that's what you really want to do.
890
 
 
891
 
 
892
 
Example OpenERP 6.0 buildout
893
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
894
 
 
895
 
Here is a sample buildout with version specification, 2 OpenERP servers (with
896
 
one using the latest 6.0 branch on the launchpad) using only NETRPC and
897
 
listening on 2 different ports, and 2 web clients::
898
 
 
899
 
    [buildout]
900
 
    parts = openerp1 web1 openerp2 web2
901
 
    #allow-picked-versions = false
902
 
    versions = versions
903
 
    find-links = http://download.gna.org/pychart/
904
 
    
905
 
    [openerp1]
906
 
    recipe = anybox.recipe.openerp:server
907
 
    version = 6.0.3
908
 
    options.xmlrpc = False
909
 
    options.xmlrpcs = False
910
 
    
911
 
    [web1]
912
 
    recipe = anybox.recipe.openerp:webclient
913
 
    version = 6.0.3
914
 
    
915
 
    [openerp2]
916
 
    recipe = anybox.recipe.openerp:server
917
 
    version = bzr lp:openobject-server/6.0 openobject-server-6.x last:1
918
 
 
919
 
    options.xmlrpc = False
920
 
    options.xmlrpcs = False
921
 
    options.netrpc_port = 8170
922
 
    
923
 
    [web2]
924
 
    recipe = anybox.recipe.openerp:webclient
925
 
    version = 6.0.3
926
 
    global.openerp.server.port = '8170'
927
 
    global.server.socket_port = 8180
928
 
    
929
 
    [versions]
930
 
    MarkupSafe = 0.15
931
 
    Pillow = 1.7.7
932
 
    anybox.recipe.openerp = 0.9
933
 
    caldav = 0.1.10
934
 
    collective.recipe.cmd = 0.5
935
 
    coverage = 3.5
936
 
    distribute = 0.6.25
937
 
    feedparser = 5.0.1
938
 
    lxml = 2.1.5
939
 
    mako = 0.4.2
940
 
    nose = 1.1.2
941
 
    psycopg2 = 2.4.2
942
 
    pychart = 1.39
943
 
    pydot = 1.0.25
944
 
    pyparsing = 1.5.6
945
 
    python-dateutil = 1.5
946
 
    pytz = 2012b
947
 
    pywebdav = 0.9.4.1
948
 
    pyyaml = 3.10
949
 
    reportlab = 2.5
950
 
    vobject = 0.8.1c
951
 
    z3c.recipe.scripts = 1.0.1
952
 
    zc.buildout = 1.5.2
953
 
    zc.recipe.egg = 1.3.2
954
 
    Babel = 0.9.6
955
 
    FormEncode = 1.2.4
956
 
    simplejson = 2.1.6
957
 
 
958
 
 
959
 
Other sample buildouts
960
 
~~~~~~~~~~~~~~~~~~~~~~
961
 
 
962
 
Here are a few ready-to-use buildouts:
963
 
 
964
 
(Be sure to install system dependencies_ first)
965
 
 
966
 
OpenERP with the development branches of the Magento connector addons::
967
 
 
968
 
  $ hg clone https://bitbucket.org/anybox/openerp_connect_magento_buildout
969
 
  $ cd openerp_connect_magento_buildout
970
 
  $ python bootstrap.py
971
 
  $ bin/buildout
972
 
  $ bin/start_openerp
973
 
 
974
 
OpenERP with the development branches of the Prestashop connector addons::
975
 
 
976
 
  $ hg clone https://bitbucket.org/anybox/openerp_connect_prestashop_buildout
977
 
  $ cd openerp_connect_prestashop_buildout
978
 
  $ python bootstrap.py
979
 
  $ bin/buildout
980
 
  $ bin/start_openerp
981
 
 
982
 
Other examples are available in the ``buildbot`` subdirectory of the
983
 
source distribution archive of this recipe (the ``tar.gz`` file that
984
 
can be downloaded `from the PyPI
985
 
<http://pypi.python.org/pypi/anybox.recipe.openerp>`_), and are
986
 
continuously tested in the
987
 
`anybox buildbot <http://buildbot.anybox.fr/>`_ which is powered by
988
 
`anybox.buildbot.openerp <http://pypi.python.org/pypi/anybox.buildbot.openerp>`_.
989
 
 
990
 
 
991
 
Contribute
992
 
~~~~~~~~~~
993
 
 
994
 
Authors:
995
 
 
996
 
 * Christophe Combelles
997
 
 * Georges Racinet
998
 
 
999
 
Contributors:
1000
 
 
1001
 
 * Jean-Sébastien Suzanne
1002
 
 * Yannick Vaucher
1003
 
 * Jacques-Etienne Baudoux
1004
 
 * Laurent Mignon
1005
 
 * Leonardo Pistone
1006
 
 
1007
 
The primary branch is on the launchpad:
1008
 
 
1009
 
 * Code repository and bug tracker: https://launchpad.net/anybox.recipe.openerp
1010
 
 * PyPI page: http://pypi.python.org/pypi/anybox.recipe.openerp
1011
 
 
1012
 
Please don't hesitate to give feedback and especially report bugs or
1013
 
ask for new features through launchpad at this URL: https://bugs.launchpad.net/anybox.recipe.openerp/+bugs
1014