anybox.recipe.openerp 1.6.3

This is a Buildout recipe that can
download, install and configure one or several OpenERP servers, web clients,
gtk clients and addons modules, from official or custom sources, or any bzr,
hg, git or svn repositories. It currently supports versions 6.0, 6.1 and 7.0,
with gunicorn deployment and an additional cron worker. It works under Linux
and MacOs. It might work under Windows but it is untested.

A “Buildout recipe” is the engine behind a Buildout “part”. A “buildout part”
is a part of a larger application built with the Buildout sandbox build system.
Using Buildout is harmless for your system because it is entirely
self-contained in a single directory: just delete the directory and the
buildout is gone. You never have to use administrative rights, except for
build dependencies.

The behaviour of this option is slightly modified :
by default, no script other than those directly related to OpenERP are
generated, but you may specify some explicitely, with the same semantics as the
normal behaviour (we simply set an empty default value, which means to not
produce scripts):

With the gtklcient and webclient recipes,
this is the default interpreter option of zc.recipe.egg that
specifies the name of the Python interpreter that shoud be included in
the“bin“ directory of the buildout:

interpreter = erp_python

With the server recipe, the interpreter option will be ignored,
because it always creates an interpreter with preloaded objects to
bootstrap openerp. Check the interpreter_name option below for
more details.

As you can see in that example, the first token is the target
filesystem path, as in the addons option, the second one is the
revision, except in the case of the main software (if VCS based), for
which there’s no filesystem path.

Some interesting use-cases:

temporary fixing some revision in cas of upstream regression with no
impact on your main development configuration (no risk to commit an
unwanted freeze if the main configuration is itself versionned).

freezing satisfactory revisions in a release process (the recipe can
do that automatically for you, see freeze-to option below).

OpenERP startup scripts are created in the bin directory. By default the name is:
start_<part_name>, so you can have several startup scripts for each part if you
configure several OpenERP servers or clients. You can pass additional typical
arguments to the server via the startup script, such as -i or -u options.

You can choose another name for the script by using the script_name
option

The recipe will automatically create a python interpreter with a
session object that can bootstrap OpenERP with a database right
away. You can use that for interactive sessions or to launch a script:

$ bin/python_openerp
To start the OpenERP working session, just do:
session.open()
or
session.open(db=DATABASE_NAME)
Then you can issue commands such as
session.registry('res.users').browse(session.cr, 1, 1)
>>>

The interpreter name is python_<part_name> by default; but it can
be explicitely set like this:

interpreter_name = my_py

If you want not to have the interpreter, juste do

interpreter_name =

The bootstrapping facility may also be used within a script installed
by an egg; just insert this in your code to get the session object as
if you were in the interpreter:

from anybox.recipe.openerp.startup import Session
session = Session()

Note

this facility is new in version 1.6.0, and tested with
OpenERP 7 only for now.

Specifies a delay in seconds to wait before actually launching OpenERP. This
option was a preliminary hack to support both gunicorn instance and a legacy
instance. The Gunicorn startup script (see below) itself is not affected by
this setting

Allows to load development and install useful devlopment and testing
tools, notably the following scripts:

test_openerp: a uniform test launcher for all supported
versions. See test_script_name option below for details.

openerp_command: see openerp_command_name option below for
details. Not installed for OpenERP major versions less than or equal to 6.1.

This option is False by default, hence it’s activated this way:

with_devtools = true

It will also add some dependencies that are typical to development
setups (tests related packages etc.) and automatically load where
needed helpers, such as anybox.testing.datetime (allows to
cheat with system time).

Allows to share OpenERP downloads among several buildouts. You should put this
option in your ~/.buildout/default.cfg file. It specifies the destination
download directory for OpenERP archives. The path may be absolute or relative
to the buildout directory.

Gunicorn integration is only supported on OpenERP >= 6.1.
Any value of this option makes the recipe generate a script to start
OpenERP with Gunicorn and (new in version 1.1) a dedicated script to
handle cron jobs.

For OpenERP 6.1, the only accepted values are direct and
proxied. Any value is suitable for OpenERP >= 7

OpenERP Command Line Tools (openerp-command for short) is an
alternative set of command-line tools that may someday subsede the
current monolithic startup script. Currently experimental, but
already very useful in development mode.

It is currently enabled if the with_devtools option is on.

This works by requiring the openerp-command python
distribution, which is not on PyPI as of this writting. You may want
to use the vcsdevelop extension to get it from Launchpad:

This option is meant to produce an extension buildout configuration
that effectively freezes the variable versions and revisions of the
current configuration.

Note

supported VCSes for this feature are currently Mercurial,
Bazaar and Git (excluding Subversion).

It is meant for release processes, and as such includes some
consistency checks to avoid as much as possible issuing a frozen
configuration that could be different from what the developper or
release manager is assumed to have just tested. Namely:

it works only in offline mode (command-line -o flag). This is to
avoid fetching new revisions from VCSes or PyPI

it fails if some VCS-controlled addons or main software have local
modifications, including pending merges.

The recommended way to use it is through the command line (all
buildout options can be set this way). Here’s an example, assuming the
part is called openerp-server-1:

bin/buildout -o openerp-server-1:freeze-to=frozen.cfg

This produces a buildout configuration file named frozen.cfg,
with notably an openerp-server-1 part having a revisions option that
freezes everything.

For configurations with several openerp related parts, you can freeze
them together or in different files. This gives you flexibility in the
distributions you may want to produce from a single configuration file:

In that latter example, server.cfg will have the two server parts,
while client.cfg will have the gtkclient part only.

Note

in DVCSes cases, nothing is done to check that the locally
extracted revisions are actually pushed where they should.

Also, if the buildout configuration is itself under version
control (a good practice), it is not in the recipe scope to
commit or tag it.
You are encouraged to use an external release script for
that kind of purpose.

Warning

the recipe will also freeze python distributions installed
with the gp.vcsdevelop extension but cannot currently
protect against local modifications of these.

Following the same kind of logic as freeze-to, this option allows
to turn a buildout that aggregates from various remote sources
(tarball downloads, VCSes) into a self-contained buildout archive
directory that can be packed for easy distribution.

Note

supported VCSes for this feature are currently Mercurial,
Bazaar and Git (excluding Subversion).

Actually it extracts only the downloaded elements into a target
directory and issues a buildout configuration with local references
only. If that target directory has been itself initialized first with
the fixed elements (buildout configuration files, bootstrap scripts,
local addons), then it has all the needed elements, except eggs to
be downloaded from PyPI or the specified index site.

Here is an example, assuming the fixed elements are themselves versioned
with Mercurial:

The produced buildout configuration in the target directory is
release.cfg. So, for instance, from our test-extract archive,
the buildout can be executed like this:

python bootstrap.py && bin/buildout -c release.cfg

or further extended for system-dependent options such as port, db
connection, etc.

The extract-downloads-to options can be used for several parts
with the same target directory (same as freeze-to).

Furthermore, a default freeze-to is issued, producing a buildout
configuration called extracted_from.cfg in the target directory,
for later reference (local modification tracking) or a more
developper-friendly reproduction configuration (ready-made setup to
derive bugfix branches from).

This implication of freeze-to also has the side effect to enforce the
same rules with respect to uncommitted changes.

Python distributions managed with gp.vcsdevelop are taken into account.

You can define OpenERP options directly from the buildout file. The OpenERP
configuration files are generated by OpenERP itself in the etc directory of
the buildout during the first Buildout run. You can overwrite these options
from the recipe section of your buildout.cfg. The options in the buildout
file must be written using a dotted notation prefixed with the name of the
corresponding section of the OpenERP config file. The specified options will
just overwrite the existing options in the corresponding config files. You
don’t have to replicate all the options in your buildout.cfg. If an option
or a section does not natively exist in the openerp config file, it can be
created from there for your application.

For example you can specify the xmlrpc port for the server or
even an additional option that does not exist in the default config file:

Please note that these package will have your system install the
client part of PostgreSQL software only. If you want a
PostgreSQL server on the same host, that’s not in the recipe scope,
just install it as well.

with OpenERP 6.1 the web client is natively included in the server as a
simple module. In that case you don’t need to write a separate part for the web
client, unless that’s what you really want to do.

Other examples are available in the buildbot subdirectory of the
source distribution archive of this recipe (the tar.gz file that
can be downloaded from the PyPI), and are
continuously tested in the
anybox buildbot which is powered by
anybox.buildbot.openerp.