17
15
buildout is gone. You never have to use administrative rights, except for
18
16
build dependencies.
25
You get 3 recipes at once. The recipe to use is the following:
18
.. _buildout_conf_parts:
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).
31
Buildout configuration files are written almost in INI format, and
32
always start with a ``buildout`` section::
37
The ``parts`` option specifies which parts to install by default if
38
one runs ``bin/buildout`` with no explicit ``install`` directive.
40
Parts directly correspond to sections of the configuration file, and
41
must specify the recipe that's to be used::
44
recipe = anybox.recipe.openerp:server
46
An extra dependency of the recipe gets required at runtime like this::
48
recipe = anybox.recipe.openerp[bzr]:server
52
The configuration file can be specified from the command line::
54
bin/buildout -c buildout.local.cfg
56
Recipe options can be overridden from the command-line::
58
bin/buildout -c buildout.local.cfg openerp:clean=True openerp:xmlrpc_port=8169
60
Parts that are not listed in the ``buildout`` configuration section
61
can be explicitely installed::
63
bin/buildout install openerp funkload static-analysis
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)::
74
extends = buildout.base.cfg
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…)
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.
92
This is commonly used with the ``eggs-directory`` and
93
:ref:`openerp-downloads-directory` options, because these amount to create a
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.).
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.
29
113
recipe = anybox.recipe.openerp:server
115
.. note:: If you plan on using Launchpad's short Bazaar branch notation
116
(``lp:``), then you need to add the ``bzr`` extra-dependency::
118
recipe = anybox.recipe.openerp[bzr]:server
33
124
recipe = anybox.recipe.openerp:webclient
37
130
recipe = anybox.recipe.openerp:gtkclient
39
Default options from zc.recipe.egg
40
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
45
Consult the documentation here http://pypi.python.org/pypi/zc.recipe.egg
47
The main useful ones are below:
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,
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.
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
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
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::
87
interpreter = erp_python
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
98
The recipe also adds a few specific options:
132
.. note:: from OpenERP 7.0 onwards, the web and gtk clients aren't
135
Options for assembly and source management
136
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
103
143
Specifies the OpenERP version to use. It can be:
105
The **version number** of an official OpenERP (server, web client or gtk client)::
109
A **custom download**::
111
version = url http://example.com/openerp.tar.gz
113
An absolute or a relative **path**::
115
version = path /my/path/to/a/custom/openerp
117
A custom **bzr, hg, git or svn** branch or repository. The syntax is the same
118
as the `addons` option (see below)::
120
version = bzr lp:openobject-server/6.1 openerp61 last:1
122
A **nightly** build::
124
version = nightly 6.1 20120814-233345
126
or (dangerously unpinned version)::
128
version = nightly 6.1 latest
130
or even more dangerous::
132
version = nightly trunk latest
145
* The **version number** of an official OpenERP (server, web client or gtk client)::
149
* A **custom download**::
151
version = url http://example.com/openerp.tar.gz
153
* An absolute or a relative **path**::
155
version = path /my/path/to/a/custom/openerp
157
* A custom **bzr, hg, git or svn** branch or repository. The syntax is the same
158
as with the :ref:`addons` option::
160
recipe = anybox.recipe.openerp[bzr]:server
161
version = bzr lp:openobject-server/6.1 openerp61 last:1
163
.. note:: the ``[bzr]`` extra dependency declaration is useful for
164
resolution of the ``lp:`` address shortcuts.
166
* A **nightly** build::
168
version = nightly 6.1 20120814-233345
170
* or (dangerously unpinned version)::
172
version = nightly 6.1 latest
174
* or even more dangerous::
176
version = nightly trunk latest
223
302
* freezing satisfactory revisions in a release process (the recipe can
224
303
do that automatically for you, see ``freeze-to`` option below).
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".
314
.. warning:: developers can lose their uncommitted work with this option.
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.
232
321
Note that tarball downloads get re-extracted afresh in any case.
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:
243
* specific batch jobs
244
* introspection tools
245
* general-purposes test launchers that don't have any knowledge of
247
* actually, the main startup scripts themselves (with a default
248
configuration, of course)
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).
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).
262
One has to register exactly one console script per line.
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).
268
Suppose there is a distribution ``my.package`` with the following lines in
274
my = my.package.main:run
277
Now the following configuration extract builds a script called
278
``my_openerp1``, that can access ``session``::
284
To control the script name, just do, e.g,::
288
openerp_scripts = my=my_script
290
This will build it as ``bin/my_script``.
292
Command-line options and test launchers
293
```````````````````````````````````````
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.
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.
306
In this example, we build ``unit2``, the launcher that comes with
307
``unittest2``, and wrap it to add the database option::
311
openerp_scripts = unit2 command-line-options=-d
313
You may then run it this way::
315
bin/unit2_openerp -d unit-tests-db -- discover some/addon
317
Notice how ``--`` is used to separate the ``-d`` or
318
any recipe-related options from the options expected by the script itself.
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``
328
openerp_scripts = nosetests command-line-options=-d
330
Here's our test run with coverage and pdb post-mortem::
332
bin/nosetests-openerp -d unit-tests-db -- --nologcapture \
333
--with-coverage --pdb \
334
some/addon/tests/test_one.py
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``.
342
This allows you (for now) to control the names. For instance, to
343
replace ``bin/start_openerp`` with ``bin/oerp``, just do::
347
openerp_scripts = openerp_starter=oerp
349
Here's the list of currently available internal entry points. For
350
these, the ``command-line-options`` modifier has no effect.
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.
328
With the OpenERP buildout recipes, OpenERP options are managed
329
directly from the buildout file (usually
330
``buildout.cfg``) from the part.
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
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
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
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::
350
options.xmlrpc_port = 8069
351
options.additional_option = "foobar"
353
It will end-up in the server configuration as::
357
additional_option = "foobar"
359
For the web client you can specify the port and company url with::
361
global.server.socket_port = 8080
362
openerp-web.company.url = 'http://anybox.fr'
364
It will modify the corresponding web client config::
367
server.socket_port = 8080
370
company.url = 'http://anybox.fr'
372
.. note:: Buildout :ref:`configuration inheritance <extends>` is
373
especially useful to manage the separation between a
374
reusable buildout configuration and local settings.
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.
383
Options for executables generation and serving
384
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
366
391
.. warning:: as of version 1.7.0, this option is deprecated because of its
367
redundancy with ``openerp_scripts``.
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`.
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.
398
You can pass additional typical
372
399
arguments to the server via the startup script, such as -i or -u options.
374
401
You can choose another name for the script by using the *script_name*
377
script_name = start_erp
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::
387
To start the OpenERP working session, just do:
390
session.open(db=DATABASE_NAME)
391
Then you can issue commands such as
392
session.registry('res.users').browse(session.cr, 1, 1)
396
The interpreter name is ``python_<part_name>`` by default; but it can
397
be explicitely set like this::
399
interpreter_name = my_py
401
If you want *not* to have the interpreter, juste do
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::
409
from anybox.recipe.openerp.startup import Session
412
.. note:: this facility is new in version 1.6.0, and tested with
413
OpenERP 7 only for now.
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
427
Allows to load development and install useful devlopment and testing
428
tools, notably the following scripts:
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.
435
This option is False by default, hence it's activated this way::
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).
447
.. warning:: as of version 1.7.0, this option is deprecated because of its
448
redundancy with ``openerp_scripts``.
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::
454
test_script_name = test_erp
456
The test script takes the same arguments as the regular startup
459
bin/test_openerp --help
460
bin/test_openerp -d test_db -i purchase,sale
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.
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::
473
base_url = http://download.example.com/openerp/
475
openerp-downloads-directory
476
---------------------------
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.
486
openerp-downloads-directory = /home/user/.buildout/openerp-downloads
404
script_name = start_erp
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.
414
.. note:: new in version 1.7.0
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
420
The option is multiline. Each line specifies exactly one
421
script, and must respect the following format:
423
``ENTRY_POINT_NAME[=WISHED_SCRIPT_NAME] [MODIFIER [MODIFIER […]]]``
425
Each modifier takes the ``MODIFIER_NAME=MODIFIER_VALUE`` form.
426
No whitespace is allowed in modifiers, entry point, nor produced script names.
428
Here's the list of currently available modifiers, with links inside :doc:`the
429
dedicated chapter about OpenERP scripts </scripts>`).
431
:command-line-options: :ref:`command_line_options`
432
:arguments: :ref:`arguments_session`
436
openerp_scripts = my_script arguments=session
437
my_other_script=actual-script-name arguments=3,session
438
nosetests=nosetests command-line-options=-d
441
.. _upgrade_script_name:
446
This option lets you specify the wished name for the upgrade script.
447
The default value is ``upgrade_<part_name>``.
449
.. note:: new in version 1.8.0.
451
We are actually not sure to keep that option, since it's
452
redundant with :ref:`openerp_scripts`.
460
.. note:: new in version 1.8.0
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
466
upgrade_script = upgrade.py run
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.
472
If you want *not* to have an upgrade script, just override this option
477
See the full :ref:`upgrade_scripts` documentation to learn more
478
about upgrade scripts.
480
.. note:: new in version 1.8.0
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.
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
580
576
``oe`` is the classical name for this script outside of the realm of
581
577
this buildout recipe.
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::
585
extensions = gp.vcsdevelop
586
vcs-extend-develop = bzr+http://bazaar.launchpad.net/openerp/openerp-command@419#egg=openerp-command
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``.
585
Do not use to launch production servers, especially in an automatic
586
way, openerp-command is really unstable and that may damage your
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.
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.
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).
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``.
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
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
634
Options for development, QA and introspection
635
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
641
Allows to load development and install useful devlopment and testing
642
tools, notably the following scripts:
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.
649
This option is False by default, hence it's activated this way::
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).
660
.. _test_script_name:
664
.. warning:: as of version 1.7.0, this option is deprecated because of its
665
redundancy with :ref:`openerp_scripts`.
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::
671
test_script_name = test_erp
673
The test script takes the same arguments as the regular startup
676
bin/test_openerp --help
677
bin/test_openerp -d test_db -i purchase,sale
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.
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``).
688
.. _interpreter_name:
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::
698
To start the OpenERP working session, just do:
701
session.open(db=DATABASE_NAME)
702
Then you can issue commands such as
703
session.registry('res.users').browse(session.cr, 1, 1)
707
The interpreter name is ``python_<part_name>`` by default; but it can
708
be explicitely set like this::
710
interpreter_name = my_py
712
If you want *not* to have the interpreter, juste do
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`.
720
.. note:: this facility is new in version 1.6.0, and tested with
721
OpenERP ≥ 6.1 only for now.
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::
730
interpreter = erp_python
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.
740
Options for download and caching strategies
741
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
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
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.
757
The OpenERP recipes define a few more.
764
This option is local to the *part*.
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::
770
base_url = http://download.example.com/openerp/
773
.. _openerp-downloads-directory:
775
openerp-downloads-directory
776
---------------------------
777
This is an option for the ``[buildout]`` section
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.
787
openerp-downloads-directory = /home/user/.buildout/openerp-downloads
791
Options for release and packaging
792
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
698
912
same rules with respect to uncommitted changes.
700
914
Python distributions managed with ``gp.vcsdevelop`` are taken into account.
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
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
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::
722
options.xmlrpc_port = 8069
723
options.additional_option = "foobar"
725
It will end-up in the server config as::
729
additional_option = "foobar"
731
For the web client you can specify the company url with::
733
global.server.socket_port = 8080
734
openerp-web.company.url = 'http://anybox.fr'
736
It will modify the corresponding web client config::
739
server.socket_port = 8080
742
company.url = 'http://anybox.fr'
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
753
How to create and bootstrap a buildout
754
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
756
To create a buildout and run the build, you just need **1 file** and **2 commands**:
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``
763
The same with more details below :
765
Creating the buildout
766
---------------------
768
Create a ``buildout.cfg`` file in an empty directory, containing the
769
configuration of the `example 6.1`_ section.
773
Installing build dependencies
774
-----------------------------
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
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:
783
Add the following line in your ``/etc/apt/sources.list``::
785
deb http://apt.anybox.fr/openerp common main
787
Install the dependency package::
789
$ sudo aptitude update
790
$ sudo aptitude install openerp-server-system-build-deps
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 ::
796
$ sudo aptitude install openerp-server-system-run-deps
797
$ sudo aptitude remove openerp-server-system-build-deps
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.
804
Bootstrapping the buildout
805
--------------------------
807
Bootstrapping the buildout consists in creating the basic structure of the buildout, and installing buildout itself in the directory.
809
The easiest and recommended way to bootstrap is to use a ``bootstrap.py`` script::
811
$ wget https://raw.github.com/buildout/buildout/master/bootstrap/bootstrap.py
812
$ python bootstrap.py
814
As an alternative and more complicated solution, you may also bootstrap by
815
creating a virtualenv, installing zc.buildout, then run the bootstrap::
818
$ sandbox/bin/pip install zc.buildout
819
$ sandbox/bin/buildout bootstrap
838
Example OpenERP 6.1 buildout
839
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
841
Here is a very simple example for a latest OpenERP 6.1 nightly and a
842
custom addon hosted on Bitbucket:
849
find-links = http://download.gna.org/pychart/
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
870
python-dateutil = 1.5
872
python-openid = 2.2.5
883
zc.recipe.egg = 1.3.2
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.
892
Example OpenERP 6.0 buildout
893
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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::
900
parts = openerp1 web1 openerp2 web2
901
#allow-picked-versions = false
903
find-links = http://download.gna.org/pychart/
906
recipe = anybox.recipe.openerp:server
908
options.xmlrpc = False
909
options.xmlrpcs = False
912
recipe = anybox.recipe.openerp:webclient
916
recipe = anybox.recipe.openerp:server
917
version = bzr lp:openobject-server/6.0 openobject-server-6.x last:1
919
options.xmlrpc = False
920
options.xmlrpcs = False
921
options.netrpc_port = 8170
924
recipe = anybox.recipe.openerp:webclient
926
global.openerp.server.port = '8170'
927
global.server.socket_port = 8180
932
anybox.recipe.openerp = 0.9
934
collective.recipe.cmd = 0.5
945
python-dateutil = 1.5
951
z3c.recipe.scripts = 1.0.1
953
zc.recipe.egg = 1.3.2
959
Other sample buildouts
960
~~~~~~~~~~~~~~~~~~~~~~
962
Here are a few ready-to-use buildouts:
964
(Be sure to install system dependencies_ first)
966
OpenERP with the development branches of the Magento connector addons::
968
$ hg clone https://bitbucket.org/anybox/openerp_connect_magento_buildout
969
$ cd openerp_connect_magento_buildout
970
$ python bootstrap.py
974
OpenERP with the development branches of the Prestashop connector addons::
976
$ hg clone https://bitbucket.org/anybox/openerp_connect_prestashop_buildout
977
$ cd openerp_connect_prestashop_buildout
978
$ python bootstrap.py
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>`_.
996
* Christophe Combelles
1001
* Jean-Sébastien Suzanne
1003
* Jacques-Etienne Baudoux
1007
The primary branch is on the launchpad:
1009
* Code repository and bug tracker: https://launchpad.net/anybox.recipe.openerp
1010
* PyPI page: http://pypi.python.org/pypi/anybox.recipe.openerp
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