Merge lp:~therp-nl/anybox.recipe.openerp/jbaudoux-relative_paths_resolve_conflict into lp:~jbaudoux/anybox.recipe.openerp/20130908_relative_paths

[Stefan Rijnhart (Opener)]

Update with trunk branch to resolve a small conflict (ll.1200-1202 in the diff).

[lp:~therp-nl/anybox.recipe.openerp/jbaudoux-relative_paths_resolve_conflict]

425. By Stefan Rijnhart (Opener) on 2014-02-06

[FIX] Use unquoted substitution

Unmerged revisions

425. By Stefan Rijnhart (Opener) on 2014-02-06

[FIX] Use unquoted substitution

424. By Stefan Rijnhart (Opener) on 2014-02-05

[MRG] Update with target branch

=== modified file '.bzrignore'
--- .bzrignore	2013-09-07 12:04:02 +0000
+++ .bzrignore	2014-02-06 07:42:46 +0000
@@ -11,3 +11,4 @@
 buildbot/develop-eggs/
 buildbot/etc/
 buildbot/parts/
+doc/sphinx_build
 
=== modified file 'CHANGES.rst'
--- CHANGES.rst	2013-09-07 11:43:18 +0000
+++ CHANGES.rst	2014-02-06 07:42:46 +0000
@@ -1,13 +1,53 @@
 Changes
 ~~~~~~~
 
-1.8.0 (unreleased)
-------------------
+The 1.7 series are stable versions, while the 1.8 are unstable.
+Changes displayed as "unreleased" in th stable series are released
+with any higher released unstable versions.
+
+1.8.2 (unreleased)
+------------------
+- launchpad #1275168: when freeze nightly version was not set correctly
+- launchpad #1245261: new ``--init-all`` option in ``test_openerp``
+  and ``start_openerp`` scripts.
+
+1.8.1 (2013-10-17)
+------------------
+- launchpad #1235946 (demo data): consistent behaviour and capability
+  to load them.
+- launchpad #1239721: now session has 'is_initialization' attribute for
+  creation use-cases of upgrade script; using it to improve logging,
+  and in default upgrade script.
+
+
+1.8.0 (2013-10-01)
+------------------
+- launchpad #1222482: upgrade toolkit and upgrade scripts generation
 - launchpad #1222116: [Gunicorn] option to preload databases
 
-1.7.2 (unreleased)
-------------------
-
+1.7.4 (unreleased)
+------------------
+- launchpad #1246822: restored the ordering of addons_path as it was
+  in 1.7.0 (main addons first).
+
+1.7.3 (2013-10-17)
+------------------
+- Fixed the licence in ``setup.py`` and hence on PyPI page. The ZPL
+  indicated was contradictory with what is stated on Launchpad's
+  project page, and plain non applicable, since the recipe *does* import
+  from OpenERP.
+- launchpad #1232806: custom interpreter and openerp_scripts now work
+  with OpenERP 6.1
+- launchpad #1233606: [bzr] lightweight checkout now respects --offline
+
+1.7.2 (2013-09-29)
+------------------
+- launchpad #1232724: [gunicorn] properly switching openerp to
+  multi-process mode
+- SAAS versions now recognized, and treated as X.5
+- launchpad #1228997: [v5] in some cases, start_openerp --stop-after-init was
+  not honoured.
+- launchpad #1222562: [git] error in extract-downloads-to
 
 1.7.1 (2013-09-07)
 ------------------
 
=== modified file 'MANIFEST.in'
--- MANIFEST.in	2012-11-07 18:41:15 +0000
+++ MANIFEST.in	2014-02-06 07:42:46 +0000
@@ -2,3 +2,4 @@
 include anybox/recipe/openerp/openerp-cron-worker
 include buildbot/*.cfg
 include buildbot/bootstrap.py
+include anybox/recipe/openerp/upgrade.py.tmpl
 \ No newline at end of file
 
=== added file 'README.rst'
--- README.rst	1970-01-01 00:00:00 +0000
+++ README.rst	2014-02-06 07:42:46 +0000
@@ -0,0 +1,75 @@
+OpenERP buildout recipe
+=======================
+This recipe for `Buildout <https://github.com/buildout/buildout>`_ is
+a fully featured tool allowing you to define and deploy quickly
+OpenERP installations of any kinds, ranging from development setups to
+fully automated production deployments or continuous integration.
+
+Some of its main features include:
+
+* uniformity across OpenERP versions (from 5.0 onwards)
+* installation of OpenERP server and, if meaningful, GTK and web clients.
+* retrieval of main software and addons from various sources,
+  including the major version control systems
+* ability to pinpoint everything for replayability
+* management of OpenERP configuration
+* dedicated scripts creation for easy integration of external tools,
+  such as test launchers
+* packaging: creation of self-contained equivalents for easy
+  deployment in tightly controlled hosting environmenents.
+
+All these to be considered together with zc.buildout‘s general
+properties, such as an extensible configuration file format for easy
+variation or separation of concerns, native Python distributions
+installation, and of course the huge ecosystem of other recipes.
+
+The `full documentation
+<http://pythonhosted.org/anybox.recipe.openerp>`_
+is written with `Sphinx
+<http://sphinx-doc.org>`_, built continuously and
+uploaded to http://docs.anybox.fr/anybox.recipe.openerp by Anybox' public
+buildbot.
+The Sphinx source tree is to be found under the ``doc`` subdirectory
+of this project.
+
+The latest released version of the documentation is uploaded to PyPI
+alongside with the package. See `PyPIDocumentationHosting
+<https://wiki.python.org/moin/PyPiDocumentationHosting>`_ for details.
+
+Bug reports and Feedback
+~~~~~~~~~~~~~~~~~~~~~~~~
+Please don't hesitate to give feedback and especially report bugs or
+ask for new features through launchpad at this URL:
+https://bugs.launchpad.net/anybox.recipe.openerp/+bugs
+
+Useful links
+~~~~~~~~~~~~
+
+* Code repository and bug tracker: https://launchpad.net/anybox.recipe.openerp
+* PyPI page: http://pypi.python.org/pypi/anybox.recipe.openerp
+* Main documentation: http://docs.anybox.fr/anybox.recipe.openerp
+
+
+Contributors information
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+See `the latest version of the contributors documentation
+<http://docs.anybox.fr/anybox.recipe.openerp/trunk/contributing.html>`_.
+
+
+Credits
+~~~~~~~
+
+Authors:
+
+ * Christophe Combelles
+ * Georges Racinet
+
+Contributors:
+
+ * Jean-Sébastien Suzanne
+ * Yannick Vaucher
+ * Jacques-Etienne Baudoux
+ * Laurent Mignon
+ * Leonardo Pistone
+
 
=== modified file 'anybox/recipe/openerp/base.py'
--- anybox/recipe/openerp/base.py	2013-09-08 13:48:02 +0000
+++ anybox/recipe/openerp/base.py	2014-02-06 07:42:46 +0000
@@ -37,6 +37,13 @@
 
 class MainSoftware(object):
     """Placeholder to represent the main software instead of an addon location.
+
+    Should just have a singleton instance: :data:`main_software`,
+    whose meaning depends on the concrete recipe class using it.
+
+    For example, in :class:`anybox.recipe.openerp.server.ServerRecipe`,
+    :data:`main_software` represents the OpenObject server or the OpenERP
+    standard distribution.
     """
 
     def __str__(self):
@@ -51,24 +58,32 @@
     """Base class for other recipes.
 
     It implements notably fetching of the main software part plus addons.
-    The ``sources`` attributes is a dict storing how to fetch the main software
-    part and specified addons. It has the following structure:
-
-        local path -> (type, location_spec, options).
-
-        where local path is the ``main_software`` object for the main software
-        part, and otherwise a local path to an addons container.
-
-        type can be
-            - 'local'
-            - 'downloadable'
-            - one of the supported vcs
-
-        location_spec is, depending on the type, a tuple specifying how to
-        fetch : (url, None), or (vcs_url, vcs_revision) or None
-
-        addons options are typically used to specify that the addons directory
-        is actually a subdir of the specified one.
+
+    The :attr:`sources` attribute is a ``dict`` storing how to fetch the main
+    software part and the specified addons, with the following structure:
+
+       ``local path -> (type, location_spec, options)``, in which:
+
+       :local path: is either the :data:`main_software` singleton
+                    (see :class:`MainSoftware`) or a local path to an
+                    addons directory.
+       :type: can be either
+
+              * ``'local'``
+              * ``'downloadable'``
+              * one of the supported vcs
+
+       :location_spec: is, depending on the type, a tuple specifying how
+                       fetch is to be done:
+
+                       ``(url, None)``, or ``(vcs_url, vcs_revision)``
+                       or ``None``
+       :addons options: are typically used to specify that the addons
+                        directory is actually a subdir of the specified one.
+
+                        VCS support classes (see
+                        :mod:`anybox.recipe.openerp.vcs`) can implemented their
+                        dedicated options
 
     """
 
@@ -164,7 +179,7 @@
         self.parse_revisions(options)
 
     def parse_version(self):
-        """Set the main software in ``sources`` and related attributes.
+        """Set the main software in :attr:`sources` and related attributes.
         """
         self.version_wanted = self.options.get('version')
         if self.version_wanted is None:
@@ -438,9 +453,9 @@
             os.putenv('PYTHONPATH', pythonpath_bak)
 
     def parse_addons(self, options):
-        """Parse the addons options into the ``sources`` attribute.
+        """Parse the addons options into :attr:`sources`.
 
-        See ``BaseRecipe`` docstring for details about the ``sources`` dict.
+        See :class:`BaseRecipe` for the structure of :attr:`sources`.
         """
 
         for line in options.get('addons', '').split(os.linesep):
@@ -462,11 +477,13 @@
             self.sources[addons_dir] = (loc_type, location_spec, options)
 
     def parse_revisions(self, options):
-        """Parse revisions options and update the ``sources`` attribute.
+        """Parse revisions options and update :attr:`sources`.
 
-        It is assumed that ``sources`` has already been populated, and
-        notably has a main_software part.
+        It is assumed that :attr:`sources` has already been populated, and
+        notably has a :data:`main_software` entry.
         This allows for easy fixing of revisions in an extension buildout
+
+        See :class:`BaseRecipe` for the structure of :attr:`sources`.
         """
         for line in options.get('revisions', '').split(os.linesep):
             # GR inline comment should have not gone through, but sometimes
@@ -505,11 +522,9 @@
                                         + source[2:])
 
     def retrieve_addons(self):
-        """Parse the addons option line, download and return a list of paths.
+        """Peform all lookup and downloads specified in :attr:`sources`.
 
-        syntax: repo_type repo_url repo_dir repo_rev [options]
-              or an absolute or relative path
-        options are themselves in the key=value form
+        See :class:`BaseRecipe` for the structure of :attr:`sources`.
         """
         self.addons_paths = []
         for local_dir, source_spec in self.sources.items():
@@ -623,7 +638,10 @@
         logger.info("No need to re-download %s", self.archive_path)
 
     def retrieve_main_software(self):
-        """install server, webclient or gtkclient."""
+        """Lookup or fetch the main software.
+
+        See :class:`MainSoftware` and :class:`BaseRecipe` for explanations.
+        """
 
         source = self.sources[main_software]
         type_spec = source[0]
@@ -751,7 +769,7 @@
     def dump_nightly_latest_version(self):
         """After download/analysis of 'nightly latest', give equivalent spec.
         """
-        return ' '.join((self.nightly_series, 'nightly', self.nightly_version))
+        return ' '.join(('nightly', self.nightly_series, self.nightly_version))
 
     def freeze_to(self, out_config_path):
         """Create an extension buildout freezing current revisions & versions.
@@ -1141,7 +1159,7 @@
         else:
             base_addons = join(self.openerp_dir, 'openerp', 'addons')
         if os.path.exists(base_addons):
-            self.addons_paths.append(base_addons)
+            self.addons_paths.insert(0, base_addons)
 
         if check_existence:
             for path in self.addons_paths:
 
=== added directory 'anybox/recipe/openerp/runtime'
=== added file 'anybox/recipe/openerp/runtime/__init__.py'
--- anybox/recipe/openerp/runtime/__init__.py	1970-01-01 00:00:00 +0000
+++ anybox/recipe/openerp/runtime/__init__.py	2014-02-06 07:42:46 +0000
@@ -0,0 +1,39 @@
+"""
+Runtime
+=======
+
+This subpackage provides encapsulations and entry points for the application
+itself:
+
+* the ``session`` module features the supporting objects for "OpenERP scripts"
+  and the dedicated python interpreter.
+* the ``start_openerp`` and ``test_openerp`` modules are the entry points for
+  the main startup scripts.
+
+This architecture is meant in particular to provide stability and uniformity
+accross OpenERP major versions, so that the recipe can be leveraged by
+automated deploymnent tools and continuous integration systems.
+"""
+
+_imported_addons = set()
+
+
+def already_imported(module_name):
+    """Convenience to help some OpenERP modules to avoid been imported twice.
+
+    Each call of this function returns a boolean indicated whether the
+    specified module was already in the ``imported_addons`` registry and add it
+    inconditionnally.
+
+    Thus caller code is expected to import the module right away if the
+    return value was False.
+    """
+    name = module_name.rsplit('.', 1)[-1]
+    if name in _imported_addons:
+        return True
+    _imported_addons.add(name)
+    return False
+
+
+def clear_import_registry():
+    _imported_addons.clear()
 
=== added directory 'anybox/recipe/openerp/runtime/backports'
=== added file 'anybox/recipe/openerp/runtime/backports/__init__.py'
--- anybox/recipe/openerp/runtime/backports/__init__.py	1970-01-01 00:00:00 +0000
+++ anybox/recipe/openerp/runtime/backports/__init__.py	2014-02-06 07:42:46 +0000
@@ -0,0 +1,1 @@
+# python package
 
=== added directory 'anybox/recipe/openerp/runtime/backports/cli'
=== added file 'anybox/recipe/openerp/runtime/backports/cli/__init__.py'
--- anybox/recipe/openerp/runtime/backports/cli/__init__.py	1970-01-01 00:00:00 +0000
+++ anybox/recipe/openerp/runtime/backports/cli/__init__.py	2014-02-06 07:42:46 +0000
@@ -0,0 +1,1 @@
+# python package
 
=== added file 'anybox/recipe/openerp/runtime/backports/cli/server.py'
--- anybox/recipe/openerp/runtime/backports/cli/server.py	1970-01-01 00:00:00 +0000
+++ anybox/recipe/openerp/runtime/backports/cli/server.py	2014-02-06 07:42:46 +0000
@@ -0,0 +1,87 @@
+# -*- coding: utf-8 -*-
+
+##############################################################################
+#
+#    OpenERP, Open Source Management Solution
+#    Copyright (C) 2004-2009 Tiny SPRL (<http://tiny.be>).
+#
+#    This program is free software: you can redistribute it and/or modify
+#    it under the terms of the GNU Affero General Public License as
+#    published by the Free Software Foundation, either version 3 of the
+#    License, or (at your option) any later version.
+#
+#    This program is distributed in the hope that it will be useful,
+#    but WITHOUT ANY WARRANTY; without even the implied warranty of
+#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#    GNU Affero General Public License for more details.
+#
+#    You should have received a copy of the GNU Affero General Public License
+#    along with this program.  If not, see <http://www.gnu.org/licenses/>.
+#
+##############################################################################
+#
+# anybox.recipe.openerp is also under AGPL v3+
+#
+
+"""
+Copied from OpenERP 6.1's openerp-server startup script.
+
+This makes utilitary functions available to the session module.
+"""
+
+import logging
+import os
+import sys
+
+try:
+    import openerp
+except:
+    # this file must stay importable by nose tests
+    pass
+else:
+    __author__ = openerp.release.author
+    __version__ = openerp.release.version
+
+    if openerp.release.version_info < (6, 1):
+        raise RuntimeError("Interpreter and scripts not compatible "
+                           "with OpenERP < 6.1")
+
+# Also use the `openerp` logger for the main script.
+_logger = logging.getLogger('openerp')
+
+
+def check_root_user():
+    """ Exit if the process's user is 'root' (on POSIX system)."""
+    if os.name == 'posix':
+        import pwd
+        if pwd.getpwuid(os.getuid())[0] == 'root':
+            sys.stderr.write("Running as user 'root' is a security risk, "
+                             "aborting.\n")
+            sys.exit(1)
+
+
+def check_postgres_user():
+    """ Exit if the configured database user is 'postgres'.
+
+    This function assumes the configuration has been initialized.
+    """
+    config = openerp.tools.config
+    if config['db_user'] == 'postgres':
+        sys.stderr.write("Using the database user 'postgres' is a "
+                         "security risk, aborting.")
+        sys.exit(1)
+
+
+def report_configuration():
+    """ Log the server version and some configuration values.
+
+    This function assumes the configuration has been initialized.
+    """
+    config = openerp.tools.config
+    _logger.info("OpenERP version %s", __version__)
+    for name, value in [('addons paths', config['addons_path']),
+                        ('database hostname',
+                         config['db_host'] or 'localhost'),
+                        ('database port', config['db_port'] or '5432'),
+                        ('database user', config['db_user'])]:
+        _logger.info("%s: %s", name, value)
 
=== renamed file 'anybox/recipe/openerp/patch_openerp_v5.py' => 'anybox/recipe/openerp/runtime/patch_openerp_v5.py'
=== renamed file 'anybox/recipe/openerp/startup.py' => 'anybox/recipe/openerp/runtime/session.py'
--- anybox/recipe/openerp/startup.py	2013-07-24 15:59:29 +0000
+++ anybox/recipe/openerp/runtime/session.py	2014-02-06 07:42:46 +0000
@@ -1,69 +1,369 @@
 """Utilities to start a server process."""
 import warnings
 import sys
+import os
 import logging
+from distutils.version import Version
+
+
 try:
     import openerp
 except ImportError:
     warnings.warn("This must be imported with a buildout openerp recipe "
                   "driven sys.path", RuntimeWarning)
 else:
-    from openerp.cli import server as startup
+    try:
+        from openerp.cli import server as startup
+    except ImportError:
+        from .backports.cli import server as startup
     from openerp.tools import config
+    from openerp import SUPERUSER_ID
+    from openerp.tools.parse_version import parse_version
+
 from optparse import OptionParser  # we support python >= 2.6
 
 logger = logging.getLogger(__name__)
 
+DEFAULT_VERSION_PARAMETER = 'buildout.db_version'
+
+DEFAULT_VERSION_FILE = 'VERSION.txt'
+
+
+class OpenERPVersion(Version):
+    """OpenERP idea of version, wrapped in a class.
+
+    This is based on :meth:`openerp.tools.parse_version`, and
+    Provides straight-ahead comparison with tuples of integers, or
+    distutils Version classes.
+    """
+
+    def parse(self, incoming):
+        if isinstance(incoming, OpenERPVersion):
+            self.vstring = incoming.vstring
+            self.components = incoming.components
+        else:
+            self.vstring = incoming
+            self.components = parse_version(incoming)
+
+    def __str__(self):
+        return self.vstring
+
+    def __repr__(self):
+        return 'OpenERPVersion(%r)' % str(self)
+
+    def __cmp__(self, other):
+        if isinstance(other, tuple):
+            other = '.'.join(str(s) for s in other)
+        elif not isinstance(other, self.__class__):
+            other = str(other)  # Works with distutils' Version classes
+
+        other = self.__class__(other)
+        return cmp(self.components, other.components)
+
 
 class Session(object):
-    """A class to represent the server object.
-
-    you should have exactly one per process.
-
-    Before actual use, call the ``bootstrap`` method.
-    Then you have useful attributes/methods behaving like unit test classes:
-
-    self.cr: a cursor
-    self.uid: user id
+    """A class to give server-level access to one database.
+
+    There should be exactly one instance of this class per process.
+    It can be used for any kind of script involving OpenERP API, and provides
+    facilities for upgrade scripts (see also
+    :mod:anybox.recipe.openerp.runtime.upgrade)
+
+    Before actual use, call :meth:`open`.
+    Then you'll have useful attributes and methods reminiscent of the unit test
+    classes:
+
+    * :attr:`cr`: a cursor
+    * :attr:`uid`: user id
+    * :attr:`registry`: access to model objects
+    * :attr:`is_initialization`: True if and only if the database was not
+      initialized before the call to :meth:`open`
+
+    Example application code::
+
+       session.open(db_name="my_db")
+       admin = session.registry('res_users').browse(session.cr, session.uid, 1)
+       (...)
+       session.cr.commit()
+       session.close()
+
+    Transaction management is up to user code
+
+    Upgrade scripts writers should check the version handling properties:
+
+    * :meth:`db_version`
+    * :meth:`package_version`
+
+    Instantiation is done by passing the path to OpenERP main
+    configuration file and the path of the buildout directory.
+
+    Usually, instantiation code is written by the recipe in the body of the
+    executable "OpenERP scripts" it produces.
+    Script writers provide a callable that takes a
+    :class:`.Session` object argument and declare it as a console script entry
+    point in their distribution.
+    End users can reference such entry points in their buildout configurations
+    to have buildout produce the actual executable. See :doc:`/scripts`
+    for details.
+
+    Upgrade scripts are a special case of that process, in which the entry
+    point is actually provided by the recipe and rewraps a user-level
+    source script.
+
+    Later versions of the recipe may find a way to pass the whole buildout
+    configuration (recall that this is to be used in a separate process in
+    which the buildout configuration has not been parsed).
     """
 
-    def __init__(self, conffile):
+    def __init__(self, conffile, buildout_dir, parse_config=True):
+        self.buildout_dir = buildout_dir
+        self.openerp_config_file = conffile
+
         self._registry = self.cr = None
-        config.parse_config(['-c', conffile])
+        if parse_config:
+            config.parse_config(['-c', conffile])
 
     def ready(self):
         return self._registry is not None
 
-    def open(self, db=None):
+    def open(self, db=None, with_demo=False):
+        """Load the database
+
+        Loading an empty database in OpenERP has the side effect of installing
+        the ``base`` module. Whether to loading demo data or not has therefore
+        to be decided right away.
+
+        :param db: database name. If not specified, the same cascading of
+                   defaults as OpenERP mainstream will be applied:
+                   configuration file, psycopg2/lipq defaults.
+        :param with_demo: controls the loading of demo data for all
+                          module installations triggered by this call to
+                          :meth:`open` and further uses of :meth:`load_modules`
+                          on this :class:`Session` instance:
+
+                          * if ``True``, demo data will uniformly be loaded
+                          * if ``False``, no demo data will be loaded
+                          * if ``None``, demo data will be loaded according to
+                            the value of ``without_demo`` in configuration
+
+                          In all cases, the behaviour will stay consistent
+                          until the next call of ``open()``, but the
+                          implementation does not protect against any race
+                          conditions in OpenERP internals.
+        """
         if db is None:
             db = config['db_name']
         if not db:
-            db = ''  # default to OpenERP/psycopg2/lipbq default behaviour
+            db = ''  # expected value expected by OpenERP to start defaulting.
+
+        cnx = openerp.sql_db.db_connect(db)
+        cr = cnx.cursor()
+        self.is_initialization = not(openerp.modules.db.is_initialized(cr))
+        cr.close()
+
         startup.check_root_user()
         startup.check_postgres_user()
         openerp.netsvc.init_logger()
+
+        saved_without_demo = config['without_demo']
+        if with_demo is None:
+            with_demo = config['without_demo']
+
+        config['without_demo'] = not with_demo
+        self.with_demo = with_demo
+
         self._registry = openerp.modules.registry.RegistryManager.get(
             db, update_module=False)
+        config['without_demo'] = saved_without_demo
         self.init_cursor()
+        self.uid = SUPERUSER_ID
+
+    # A later version might read that from buildout configuration.
+    _version_parameter_name = DEFAULT_VERSION_PARAMETER
+
+    @property
+    def version_file_path(self):
+        """Absolute path of the flat file storing the package version.
+
+        For now this is not configurable, a later version might read it
+        from buildout configuration.
+        """
+        return os.path.join(self.buildout_dir, DEFAULT_VERSION_FILE)
+
+    def parse_version_string(self, vstring):
+        """Stable method for downstream code needing to instantiate a version.
+
+        This method returns an appropriate version instance, without
+        any dependency on where to import the class from. Especially useful
+        for applications whose life started before this set of utilities has
+        been used : this helps building an usable default.
+        """
+        return OpenERPVersion(vstring)
+
+    @property
+    def db_version(self):
+        """Settable property for version stored in DB of the whole buildout.
+
+        This can be thought as the latest version to which the DB has been
+        upgraded to.
+        A simple caching system to avoid querying the DB multiple times is
+        implemented.
+        """
+        db_version = getattr(self, '_db_version', None)
+        if db_version is not None:
+            return db_version
+
+        db_version = self.registry('ir.config_parameter').get_param(
+            self.cr, self.uid, self._version_parameter_name)
+        if not db_version:
+            # as usual OpenERP thinks its simpler to use False as None
+            # restoring sanity ASAP
+            db_version = None
+        else:
+            db_version = OpenERPVersion(db_version)
+        self._db_version = db_version
+        return db_version
+
+    @db_version.setter
+    def db_version(self, version):
+        self.registry('ir.config_parameter').set_param(
+            self.cr, self.uid, self._version_parameter_name, str(version))
+        self._db_version = OpenERPVersion(version)
+
+    @property
+    def package_version(self):
+        """Property reading the version file from buildout directory.
+
+        Comments introduced with a hash are accepted.
+        Only the first significant line is taken into account.
+        """
+        pkg_version = getattr(self, '_pkg_version', None)
+        if pkg_version is not None:
+            return pkg_version
+
+        try:
+            with open(self.version_file_path) as f:
+                for line in f:
+                    line = line.split('#', 1)[0].strip()
+                    if not line:
+                        continue
+                    self._pkg_version = OpenERPVersion(line)
+                    return self._pkg_version
+        except IOError:
+            logger.info("No version file could be read, "
+                        "package version considered to be None")
+
+    def update_modules_list(self):
+        """Update the list of available OpenERP modules, like the UI allows to.
+
+        This is necessary prior to install of any new module.
+        """
+        self.registry('ir.module.module').update_list(self.cr, self.uid)
 
     def init_cursor(self):
         self.cr = self._registry.db.cursor()
 
     def registry(self, model):
-        """Return the model object."""
+        """Lookup model by name and return a ready-to-work instance."""
         return self._registry.get(model)
 
     def rollback(self):
         self.cr.rollback()
 
     def close(self):
+        """Close the cursor and forget about the current database.
+
+        The session is thus ready to open another database.
+        """
+        dbname = self.cr.dbname
         self.cr.close()
+        openerp.modules.registry.RegistryManager.delete(dbname)
+
+    def update_modules(self, modules, db=None):
+        """Update the prescribed modules in the database.
+
+        :param db: Database name. If not specified, it is assumed to have
+                   already been opened with :meth:`open`, e.g, for a prior
+                   read of :meth:`db_version`.
+                   If it is specified, then the session in particular opens
+                   that db and will use it afterwards whether another one
+                   was already opened or not.
+        :param modules: any iterable of module names.
+                        Not installed modules will be ignored
+                        The special name ``'all'`` triggers the update of
+                        all installed modules.
+        """
+        if db is None:
+            if self.cr is None:
+                raise ValueError("update_modules needs either the session to "
+                                 "be opened or an explicit database name")
+            db = self.cr.dbname
+
+        if self.cr is not None:
+            self.close()
+        for module in modules:
+            config['update'][module] = 1
+        self._registry = openerp.modules.registry.RegistryManager.get(
+            db, update_module=True)
+        config['update'].clear()
+        self.init_cursor()
+
+    def install_modules(self, modules, db=None, update_modules_list=True,
+                        open_with_demo=False):
+        """Install the modules in the database.
+
+        Has the side effect of closing the current cursor, committing if and
+        only if the list of modules is updated.
+
+        Demo data loading is handled consistently with the decision taken
+        by :meth:`open`.
+
+        :param db: Database name. If not specified, it is assumed to have
+                   already been opened with :meth:`open`, e.g, for a prior
+                   read of :meth:`db_version`.
+                   If it is specified, then the session in particular opens
+                   that db and will use it afterwards whether another one
+                   was already opened or not.
+        :param modules: any iterable of module names.
+        :param update_modules_list: if True, will update the module lists
+                                    *and commit* before the install begins.
+        :param open_with_demo: if ``db`` is not None, will be passed to
+                               :meth:`open`.
+        """
+        already_open = self.cr is not None
+        if db is None:
+            if not already_open:
+                raise ValueError("install_modules needs either the session to "
+                                 "be opened or an explicit database name")
+            db = self.cr.dbname
+        elif update_modules_list and not (
+                already_open and self.cr.dbname == db):
+            self.open(db=db, with_demo=open_with_demo)
+
+        if update_modules_list:
+            self.update_modules_list()
+            self.cr.commit()
+
+        if self.cr is not None:
+            self.close()
+        saved_without_demo = config['without_demo']
+
+        # with update_modules_list=False, an explicitely named DB would not
+        # have gone through open() yet.
+        config['without_demo'] = not getattr(self, 'with_demo', open_with_demo)
+        for module in modules:
+            config['init'][module] = 1
+        self._registry = openerp.modules.registry.RegistryManager.get(
+            db, update_module=True, force_demo=self.with_demo)
+        config['init'].clear()
+        config['without_demo'] = saved_without_demo
+        self.init_cursor()
 
     def handle_command_line_options(self, to_handle):
         """Handle prescribed command line options and eat them.
 
-        Anything before first occurrence of '--' is ours and removed from
-        sys.argv.
+        Anything before first occurrence of ``--`` on the command-line is taken
+        into account and removed from ``sys.argv``.
 
         Help messages:
 
@@ -118,17 +418,3 @@
                 logger.info("No database specified, using the one specified "
                             "in buildout configuration.")
             self.open(db=options.db_name)
-
-_imported_addons = set()
-
-
-def already_imported(module_name):
-    name = module_name.rsplit('.', 1)[-1]
-    if name in _imported_addons:
-        return True
-    _imported_addons.add(name)
-    return False
-
-
-def clear_import_registry():
-    _imported_addons.clear()
 
=== renamed file 'anybox/recipe/openerp/start_openerp.py' => 'anybox/recipe/openerp/runtime/start_openerp.py'
--- anybox/recipe/openerp/start_openerp.py	2013-08-04 18:23:29 +0000
+++ anybox/recipe/openerp/runtime/start_openerp.py	2014-02-06 07:42:46 +0000
@@ -1,14 +1,38 @@
+"""This module bridges the classical ``openerp-server`` as a console script.
+
+The :func:`main` function gets registered on the fly by the server recipe as
+a console script entry point and used in particular for ``start_openerp`` and
+``test_openerp``.
+
+Some version independence logic for the startup process also get bootstrapped
+from here.
+"""
+
 import sys
 import os
 from . import patch_openerp_v5
 
 
 def insert_args(arguments):
+    """Insert `arguments` in ``sys.argv`` (direct impact on child script).
+    """
     for i, a in enumerate(arguments):
         sys.argv.insert(i+1, a)
 
 
 def main(starter, conf, version=None, just_test=False):
+    """Call the `starter` script, dispatching configuration.
+
+    All arguments are set in the standalone script produced by buildout through
+    entry point options.
+
+    :param starter: path to the main script source file (currently
+      ``openerp-server``)
+    :param conf: path to the OpenERP configuration file (managed by the recipe)
+    :param version: OpenERP major version
+    :type version: tuple of integers
+    :param just_test: if True, only run unit tests
+    """
     arguments = ['-c', conf]
 
     if just_test:
@@ -19,6 +43,16 @@
         if version >= (7, 0):
             arguments.append('--test-enable')
 
+    if '--install-all' in sys.argv:
+        sys.argv.remove('--install-all')
+        from openerp.tools import config
+        # Maybe we should preparse config in all cases and therefore avoid
+        # adding the '-c' on the fly ?
+        # Still, cautious about pre-6.1 versions
+        config.parse_config(['-c', conf])
+        from openerp.modules import get_modules
+        arguments.extend(('-i', ','.join(get_modules())))
+
     insert_args(arguments)
 
     if version == (5, 0):
@@ -28,4 +62,12 @@
     glob = globals()
     glob['__name__'] = '__main__'
     glob['__file__'] = starter
-    execfile(starter, globals())
+    try:
+        execfile(starter, globals())
+    except SystemExit as exc:
+        if version == (5, 0):
+            # Without Agent.quit() the Timer threads may go on forever
+            # and the script will never stop
+            import netsvc
+            netsvc.Agent.quit()
+        return exc.code
 
=== renamed file 'anybox/recipe/openerp/test_openerp.py' => 'anybox/recipe/openerp/runtime/test_openerp.py'
=== added directory 'anybox/recipe/openerp/runtime/tests'
=== added file 'anybox/recipe/openerp/runtime/tests/__init__.py'
--- anybox/recipe/openerp/runtime/tests/__init__.py	1970-01-01 00:00:00 +0000
+++ anybox/recipe/openerp/runtime/tests/__init__.py	2014-02-06 07:42:46 +0000
@@ -0,0 +1,1 @@
+# python package
 
=== renamed file 'anybox/recipe/openerp/tests/test_startup.py' => 'anybox/recipe/openerp/runtime/tests/test_import_registry.py'
--- anybox/recipe/openerp/tests/test_startup.py	2013-06-15 11:33:47 +0000
+++ anybox/recipe/openerp/runtime/tests/test_import_registry.py	2014-02-06 07:42:46 +0000
@@ -1,5 +1,5 @@
 from unittest import TestCase
-from ..startup import already_imported, clear_import_registry
+from .. import already_imported, clear_import_registry
 
 
 class TestImportRegistry(TestCase):
 
=== added file 'anybox/recipe/openerp/runtime/upgrade.py'
--- anybox/recipe/openerp/runtime/upgrade.py	1970-01-01 00:00:00 +0000
+++ anybox/recipe/openerp/runtime/upgrade.py	2014-02-06 07:42:46 +0000
@@ -0,0 +1,153 @@
+"""Uniform encapsulation of buildout-local upgrade script.
+
+The idea is to provide a common set of options, so that upgrade scripts all
+have the same interface, and project maintainers can focus on the decision
+taking logic.
+"""
+import os
+import sys
+import imp
+import logging
+from argparse import ArgumentParser
+from argparse import ArgumentDefaultsHelpFormatter
+from argparse import SUPPRESS
+from datetime import datetime
+from math import ceil
+
+from .session import Session
+
+DEFAULT_LOG_FILE = 'upgrade.log'
+
+
+def upgrade(upgrade_script, upgrade_callable, conf, buildout_dir):
+    """Run the upgrade from a source file.
+
+    All arguments are set in the standalone script produced by buildout through
+    entry point options.
+
+    * ``upgrade_script``: absolute path to the upgrade script python source.
+    * ``upgrade_callable``: name of the callable in source file actually
+      running the script.
+
+      It must accept the two following positional arguments, in that order:
+
+        - a :class:`.Session` instance (as in standard "OpenERP scripts")
+        - a logger (standard object from the :mod:`logging` module)
+
+      and may return a non zero status code to indicate an error.
+      Both ``None`` and 0 are interpreted as success.
+
+    * ``conf``: path to the OpenERP configuration file (managed by the recipe)
+    * ``buildout_dir``: directory of the buildout
+    """
+
+    parser = ArgumentParser(formatter_class=ArgumentDefaultsHelpFormatter,
+                            epilog="")
+    parser.add_argument('--log-file', default=DEFAULT_LOG_FILE,
+                        help="File to log sub-operations to, relative to the "
+                        "current working directory, supports homedir "
+                        "expansion ('~' on POSIX systems).")
+    parser.add_argument('--log-level', default='info',
+                        help="Main OpenERP logging level. Does not affect the "
+                        "logging from the main upgrade script itself.")
+    parser.add_argument('--console-log-level', default='info',
+                        help="Level for the upgrade process console "
+                        "logging. This is for the main upgrade script itself "
+                        "meaning that usually only major steps should be "
+                        "logged ")
+    parser.add_argument('-q', '--quiet', action='store_true',
+                        help="Suppress console output from the main upgrade "
+                             "script (lower level stages can still write)")
+    parser.add_argument('-d', '--db-name', default=SUPPRESS,
+                        help="Database name. If ommitted, the general default "
+                        "values from OpenERP config file or libpq will apply.")
+    parser.add_argument('--init-load-demo-data', action='store_true',
+                        help="Demo data will be loaded with module "
+                        "installations if and only if "
+                        "this modifier is specified")
+
+    arguments = parser.parse_args()  # 'args' would shadow the one of pdb
+    log_path = os.path.abspath(os.path.expanduser(arguments.log_file))
+    log_level = arguments.log_level
+    console_level = arguments.console_log_level.upper()
+    quiet = arguments.quiet
+
+    try:
+        log_file = open(log_path, 'a')
+    except IOError:
+        sys.stderr.write("Cannot open %r for write" % log_path + os.linesep)
+        sys.exit(-1)
+
+    session = Session(conf, buildout_dir)
+
+    from openerp.tools import config
+    config['logfile'] = log_path
+    config['log-level'] = log_level
+
+    start_time = datetime.utcnow()
+    if not quiet:
+        print("Starting upgrade, logging details to %s at level %s, "
+              "and major steps to console at level %s" % (
+                  log_path, log_level.upper(), console_level.upper()))
+        print('')
+
+    logger = logging.getLogger('openerp.upgrade')
+    console_handler = logging.StreamHandler()
+    console_handler.setLevel(getattr(logging, console_level))
+    console_handler.setFormatter(logging.Formatter(
+        "%(asctime)s %(levelname)s  %(message)s"))
+
+    if not arguments.quiet:
+        logger.addHandler(console_handler)
+
+    db_name = getattr(arguments, 'db_name', None)
+    logger.info("Opening database %r", db_name)
+    session.open(db=db_name, with_demo=bool(arguments.init_load_demo_data))
+    # actual value after all defaultings have been done
+    db_name = session.cr.dbname
+
+    if session.is_initialization:
+        logger.info("Database %r base initialization done. Proceeding further",
+                    db_name)
+    else:
+        logger.info("Database %r loaded. Actual upgrade begins.", db_name)
+
+    pkg_version = session.package_version
+    if pkg_version is None:
+        logger.warn("Expected package version file %r does not exist. "
+                    "version won't be set in database at the end of upgrade. "
+                    "Consider including such a version file in your project "
+                    "*before* version dependent logic is actually needed.",
+                    session.version_file_path)
+    else:
+        logger.info("Read package version: %s from %s", pkg_version,
+                    session.version_file_path)
+
+    db_version = session.db_version
+    if db_version is None:
+        if not session.is_initialization:
+            logger.warn("No version currently set in database (the present "
+                        "upgrade script has never been run). Consider setting "
+                        "database version even for fresh instances, to "
+                        "eliminate any guesswork in the upgrade scripts.")
+    else:
+        logger.info("Database latest upgrade version : %s", db_version)
+
+    upgrade_module = imp.load_source('anybox.recipe.openerp.upgrade_openerp',
+                                     upgrade_script)
+    statuscode = getattr(upgrade_module, upgrade_callable)(session, logger)
+    if statuscode is None or statuscode == 0:
+        if pkg_version is not None:
+            logger.info("setting version %s in database" % pkg_version)
+            session.db_version = pkg_version
+        session.cr.commit()
+
+        logger.info("%s successful. Total time: %d seconds." % (
+            "Initialization" if session.is_initialization else "Upgrade",
+            ceil((datetime.utcnow() - start_time).total_seconds())
+        ))
+    else:
+        logger.error("Please check logs at %s" % log_path)
+
+    log_file.close()
+    sys.exit(statuscode)
 
=== modified file 'anybox/recipe/openerp/server.py'
--- anybox/recipe/openerp/server.py	2013-09-08 17:19:27 +0000
+++ anybox/recipe/openerp/server.py	2014-02-06 07:42:46 +0000
@@ -2,6 +2,7 @@
 import os
 from os.path import join
 import sys
+import shutil
 import logging
 import subprocess
 import zc.buildout
@@ -46,13 +47,17 @@
     soft_requirements = ('openerp-command',)
     with_openerp_command = False
     with_gunicorn = False
+    with_upgrade = True
     ws = None
+    template_upgrade_script = os.path.join(os.path.dirname(__file__),
+                                           'upgrade.py.tmpl')
 
     def __init__(self, *a, **kw):
         super(ServerRecipe, self).__init__(*a, **kw)
         opt = self.options
         self.with_devtools = (
             opt.get('with_devtools', 'false').lower() == 'true')
+        self.with_upgrade = self.options.get('upgrade_script') != ''
         # discarding, because we have a special behaviour with custom
         # interpreters
         opt.pop('interpreter', None)
@@ -186,6 +191,7 @@
 timeout = %(timeout)s
 max_requests = %(max_requests)s
 
+openerp.multi_process = True  # needed even with only one worker
 openerp.conf.server_wide_modules = ['web']
 conf = openerp.tools.config
 """ % gunicorn_options
@@ -339,6 +345,29 @@
                 self.major_version),
         )
 
+    def _register_upgrade_script(self, qualified_name):
+        desc = self._get_or_create_script('openerp_upgrader',
+                                          name=qualified_name)[1]
+        script_opt = self.options.get('upgrade_script', 'upgrade.py run')
+        script = script_opt.split()
+        if len(script) != 2:
+            # TODO add console script entry point support
+            raise zc.buildout.UserError(
+                ("upgrade_script option must take the form "
+                 "SOURCE_FILE CALLABLE (got '%r')" % script))
+        script_source_path = self.make_absolute(script[0])
+        desc.update(
+            entry='openerp_upgrader',
+            arguments='%r, %r, %r, %r' % (
+                script_source_path, script[1],
+                self.config_path, self.buildout_dir),
+        )
+
+        if not os.path.exists(script_source_path):
+            logger.warning("Ugrade script source %s does not exist."
+                           "Initializing it for you", script_source_path)
+            shutil.copy(self.template_upgrade_script, script_source_path)
+
     def _register_gunicorn_startup_script(self, qualified_name):
         """Register a gunicorn foreground start script for installation.
 
@@ -448,8 +477,10 @@
 
         initialization = os.linesep.join((
             "",
-            "from anybox.recipe.openerp.startup import Session",
-            "session = Session(%s)" % self._relativitize(self.config_path),
+            "from anybox.recipe.openerp.runtime.session import Session",
+            "session = Session(%s, %r)" % (
+                    self._relativitize(self.config_path),
+                    self.buildout_dir),
             "if len(sys.argv) <= 1:",
             "    print('To start the OpenERP working session, just do:')",
             "    print('    session.open(db=DATABASE_NAME)')",
@@ -488,8 +519,9 @@
 
         common_init = os.linesep.join((
             "",
-            "from anybox.recipe.openerp.startup import Session",
-            "session = Session(%r)" % self.config_path,
+            "from anybox.recipe.openerp.runtime.session import Session",
+            "session = Session(%r, %r)" % (self.config_path,
+                                           self.buildout_dir),
         ))
 
         for script_name, desc in self.openerp_scripts.items():
@@ -518,9 +550,15 @@
 
         # provide additional needed entry points for main start/test scripts
         self.eggs_reqs.extend((
-            ('openerp_starter', 'anybox.recipe.openerp.start_openerp', 'main'),
-            ('openerp_cron_worker', 'anybox.recipe.openerp.start_openerp',
-             'main'),
+            ('openerp_starter',
+             'anybox.recipe.openerp.runtime.start_openerp',
+             'main'),
+            ('openerp_cron_worker',
+             'anybox.recipe.openerp.runtime.start_openerp',
+             'main'),
+            ('openerp_upgrader',
+             'anybox.recipe.openerp.runtime.upgrade',
+             'upgrade'),
         ))
 
         if self.major_version >= (8, 0):
@@ -551,6 +589,11 @@
                                               'cron_worker_%s' % self.name)
             self._register_cron_worker_startup_script(qualified_name)
 
+        if self.with_upgrade:
+            qualified_name = self.options.get('upgrade_script_name',
+                                              'upgrade_%s' % self.name)
+            self._register_upgrade_script(qualified_name)
+
         self._install_openerp_scripts()
 
     def _60_fix_root_path(self):
 
=== modified file 'anybox/recipe/openerp/tests/test_server.py'
--- anybox/recipe/openerp/tests/test_server.py	2013-08-25 06:31:14 +0000
+++ anybox/recipe/openerp/tests/test_server.py	2014-02-06 07:42:46 +0000
@@ -251,8 +251,8 @@
         self.recipe.retrieve_addons()
         paths = self.recipe.addons_paths
         self.recipe.finalize_addons_paths(check_existence=False)
-        self.assertEquals(paths, [addons_dir,
-                                  os.path.join(oerp_dir, 'openerp', 'addons')])
+        self.assertEquals(paths, [os.path.join(oerp_dir, 'openerp', 'addons'),
+                                  addons_dir])
 
     def test_retrieve_fixup_addons_local_60_check_ok(self):
         oerp_dir = os.path.join(TEST_DIR, 'oerp60')
@@ -268,7 +268,7 @@
         os.mkdir(addons_dir)
         self.recipe.finalize_addons_paths()
         paths = self.recipe.addons_paths
-        self.assertEqual(paths, [addons_dir, root_dir])
+        self.assertEqual(paths, [root_dir, addons_dir])
         self.assertEqual(self.recipe.options['options.root_path'],
                          os.path.join(oerp_dir, 'bin'))
 
 
=== added file 'anybox/recipe/openerp/tests/test_utils.py'
--- anybox/recipe/openerp/tests/test_utils.py	1970-01-01 00:00:00 +0000
+++ anybox/recipe/openerp/tests/test_utils.py	2014-02-06 07:42:46 +0000
@@ -0,0 +1,25 @@
+import unittest
+import tempfile
+import shutil
+import os
+
+from ..utils import working_directory_keeper
+
+
+class WorkingDirectoryTestCase(unittest.TestCase):
+
+    def setUp(self):
+        self.dirpath = tempfile.mkdtemp()
+
+    def tearDown(self):
+        shutil.rmtree(self.dirpath)
+
+    def test_ctx_manager(self):
+        # warning: if this fails, then many other tests can be
+        # affected, because many don't like being in /
+        current = os.getcwd()
+        with working_directory_keeper:
+            os.chdir(self.dirpath)
+            self.assertNotEqual(os.getcwd(), current)
+
+        self.assertEqual(os.getcwd(), current)
 
=== added file 'anybox/recipe/openerp/upgrade.py.tmpl'
--- anybox/recipe/openerp/upgrade.py.tmpl	1970-01-01 00:00:00 +0000
+++ anybox/recipe/openerp/upgrade.py.tmpl	2014-02-06 07:42:46 +0000
@@ -0,0 +1,19 @@
+# -*- python -*-
+"""This is a template upgrade script.
+
+The purpose is both to cover the most common use-case (updating all modules)
+and to provide an example of how this works.
+"""
+
+
+def run(session, logger):
+    """Update all modules."""
+    if session.is_initialization:
+        logger.warn("Usage of upgrade script for initialization detected. "
+                    "You should consider customizing the present upgrade "
+                    "script to add modules install commands. The present "
+                    "script is at : %s (byte-compiled form)",
+                    __file__)
+        return
+    logger.info("Default upgrade procedure : updating all modules.")
+    session.update_modules(['all'])
 
=== modified file 'anybox/recipe/openerp/utils.py'
--- anybox/recipe/openerp/utils.py	2013-08-27 09:29:47 +0000
+++ anybox/recipe/openerp/utils.py	2014-02-06 07:42:46 +0000
@@ -7,6 +7,9 @@
 logger = logging.getLogger(__name__)
 
 
+MAJOR_VERSION_RE = re.compile(r'(\d+)[.](\d*)(\w*)')
+
+
 class WorkingDirectoryKeeper(object):
     """A context manager to get back the working directory as it was before.
 
@@ -43,11 +46,6 @@
             yield f
 
 
-NIGHTLY_VERSION_RE = re.compile(r'(\d+)[.](\d+)-(\d+-\d+)$')
-
-MAJOR_VERSION_RE = re.compile(r'(\d+)[.](\d+)')
-
-
 def major_version(version_string):
     """The least common denominator of OpenERP versions : two numbers.
 
@@ -55,14 +53,43 @@
     releases, bzr versions etc. It's almost impossible to compare them without
     an a priori knowledge of release dates and revisions.
 
+    Here are some examples::
+
+       >>> major_version('1.2.3-foo.bar')
+       (1, 2)
+       >>> major_version('6.1-20121003-233130')
+       (6, 1)
+       >>> major_version('7.0alpha')
+       (7, 0)
+
     Beware, the packaging script does funny things, such as labeling current
     nightlies as 6.2-date-time whereas version_info is (7, 0, 0, ALPHA)
     We can in recipe code check for >= (6, 2), that's not a big issue.
+
+    Regarding OpenERP saas releases (e.g. 7.saas~1) that are short-lived stable
+    versions between two "X.0" LTS releases, the second version number does not
+    contain a numeric value. The value X.5 will be returned (e.g. 7.5)::
+
+       >>> major_version('7.saas~1')
+       (7, 5)
+
     """
 
     m = MAJOR_VERSION_RE.match(version_string)
-    if m is not None:
-        return tuple(int(m.group(i)) for i in (1, 2))
+
+    if m is None:
+        raise ValueError("Unparseable version string: %r" % version_string)
+
+    major = int(m.group(1))
+    minor = m.group(2)
+    if not minor and m.group(3).startswith('saas'):
+        return major, 5
+
+    try:
+        return major, int(minor)
+    except TypeError:
+        raise ValueError(
+            "Unrecognized second version segment in %r" % version_string)
 
 
 def mkdirp(path):
 
=== modified file 'anybox/recipe/openerp/vcs/bzr.py'
--- anybox/recipe/openerp/vcs/bzr.py	2013-09-06 12:14:37 +0000
+++ anybox/recipe/openerp/vcs/bzr.py	2014-02-06 07:42:46 +0000
@@ -213,7 +213,13 @@
 
             self.update_conf()
 
+            init_opt = self.options.get('bzr-init')
             if self.is_fixed_revision(revision):
+                if (offline and init_opt == 'lightweight-checkout'):
+                    logger.warning("Offline mode, no update for lightweight "
+                                   "checkout at %s on revision %r",
+                                   self.target_dir, revision)
+                    return
                 try:
                     self._update(revision)
                     return
@@ -225,8 +231,9 @@
                 logger.info("Offline mode, no pull for revision %r", revision)
             else:
                 self._pull()
-            if not (offline and
-                    self.options.get('bzr-init') == 'stacked-branch'):
+
+            if not (offline and init_opt in ('stacked-branch',
+                                             'lightweight-checkout')):
                 self._update(revision)
 
     def _branch(self, revision):
 
=== modified file 'anybox/recipe/openerp/vcs/git.py'
--- anybox/recipe/openerp/vcs/git.py	2013-09-06 16:21:36 +0000
+++ anybox/recipe/openerp/vcs/git.py	2014-02-06 07:42:46 +0000
@@ -82,7 +82,8 @@
 
     def archive(self, target_path):
         revision = self.parents()[0]
-        os.makedirs(target_path)
+        if not os.path.exists(target_path):
+            os.makedirs(target_path)
         with working_directory_keeper:
             os.chdir(self.target_dir)
             target_tar = tempfile.NamedTemporaryFile(
 
=== modified file 'anybox/recipe/openerp/vcs/tests/test_bzr.py'
--- anybox/recipe/openerp/vcs/tests/test_bzr.py	2013-09-06 12:14:37 +0000
+++ anybox/recipe/openerp/vcs/tests/test_bzr.py	2014-02-06 07:42:46 +0000
@@ -332,18 +332,20 @@
 
 class BzrOfflineTestCase(BzrBaseTestCase):
 
-    def make_local_branch(self, path, initial_rev):
+    def make_local_branch(self, path, initial_rev, options=None):
         """Make a local branch of the source at initial_rev and forbid pulls.
         """
+        if options is None:
+            options = {}
         target_dir = os.path.join(self.dst_dir, path)
         # initial branching (non offline
         BzrBranch(target_dir, self.src_repo)(initial_rev)
 
         # crippled offline branch
-        branch = BzrBranch(target_dir, self.src_repo, offline=True)
+        branch = BzrBranch(target_dir, self.src_repo, offline=True, **options)
 
         def _pull():
-            raise UpdateError("Should not pull !")
+            self.fail("Should not pull !")
 
         branch._pull = _pull
         return branch
@@ -373,3 +375,31 @@
         revid = branch.get_revid('1')
         branch('revid:' + revid)
         self.assertRevision1(branch)
+
+    def test_lightweight_checkout_noupdate(self):
+        """[offline mode] lightweight checkouts shall not be updated."""
+        branch = self.make_local_branch(
+            "clone to update", '1',
+            options={'bzr-init': 'lightweight-checkout'})
+
+        def _update(*a, **kw):
+            self.fail("Should not update !")
+
+        branch._update = _update
+
+        branch('last:1')
+        self.assertRevision1(branch)
+
+    def test_lightweight_checkout_noupdate_fixed_rev(self):
+        """[offline mode] lightweight checkouts shall not be updated."""
+        branch = self.make_local_branch(
+            "clone to update", 'last:1',
+            options={'bzr-init': 'lightweight-checkout'})
+
+        def _update(*a, **kw):
+            self.fail("Should not update !")
+
+        branch._update = _update
+
+        branch('1')
+        self.assertRevision2(branch)
 
=== modified file 'anybox/recipe/openerp/vcs/tests/test_git.py'
--- anybox/recipe/openerp/vcs/tests/test_git.py	2013-09-06 16:21:36 +0000
+++ anybox/recipe/openerp/vcs/tests/test_git.py	2014-02-06 07:42:46 +0000
@@ -120,6 +120,9 @@
         repo(new_sha)
         self.assertEqual(repo.parents(), [new_sha])
 
+        # see launchpad #1215873
+        repo(new_sha)
+
     def test_uncommitted_changes(self):
         """GitRepo can detect uncommitted changes."""
         # initial cloning
 
=== modified file 'buildbot/MANIFEST.cfg'
--- buildbot/MANIFEST.cfg	2013-09-07 12:04:02 +0000
+++ buildbot/MANIFEST.cfg	2014-02-06 07:42:46 +0000
@@ -1,35 +1,57 @@
 [anybox.recipe.openerp]
 watch = bzr lp:anybox.recipe.openerp
 
+[anybox.recipe.openerp-stable]
+watch = bzr lp:anybox.recipe.openerp/1.7
+
 [recipe-50]
-# A buildout to test latest version of the recipe in OpenERP 6.0 case
-# sale_margin is in extras and requires sale
-buildout = standalone recipe-50.cfg
-openerp-addons = sale_margin
-build-for = postgresql == 8.4 OR == 9.2
-watch = bzr lp:anybox.recipe.openerp
+# A buildout to test latest version of the recipe in OpenERP 5.0 case
+# sale_margin is in extras and requires sale
+buildout = bzr lp:anybox.recipe.openerp recipe-50.cfg subdir=buildbot
+openerp-addons = sale_margin
+build-for = postgresql == 8.4 OR == 9.2
+build-category = mature
+# OpenERP v5 won't work on python 2.7
+build-requires = python == 2.6
+
+[stable-recipe-50]
+# A buildout to test latest version of the recipe in OpenERP 5.0 case
+# sale_margin is in extras and requires sale
+buildout = bzr lp:anybox.recipe.openerp/1.7 stable-recipe-50.cfg subdir=buildbot
+openerp-addons = sale_margin
+build-for = postgresql == 8.4 OR == 9.2
 build-category = mature
 # OpenERP v5 won't work on python 2.7
 build-requires = python == 2.6
 
 [recipe-60]
-buildout = standalone recipe-60.cfg
-bootstrap-version = 1.7
-build-for = postgresql == 8.4
-watch = bzr lp:anybox.recipe.openerp
+buildout = bzr lp:anybox.recipe.openerp recipe-60.cfg subdir=buildbot
+bootstrap-version = 1.7
+build-for = postgresql == 8.4
+build-category = mature
+
+[stable-recipe-60]
+buildout = bzr lp:anybox.recipe.openerp/1.7 stable-recipe-60.cfg subdir=buildbot
+bootstrap-version = 1.7
+build-for = postgresql == 8.4
 build-category = mature
 
 [recipe-61]
 # A buildout to test latest version of the recipe in OpenERP 6.1 case
-buildout = standalone recipe-61.cfg
-build-for = postgresql == 9.1
-watch = bzr lp:anybox.recipe.openerp
+buildout = bzr lp:anybox.recipe.openerp recipe-61.cfg subdir=buildbot
+build-for = postgresql == 9.1
+build-category = mature
+
+[stable-recipe-61]
+# A buildout to test latest stable version of the recipe in OpenERP 6.1 case
+buildout = bzr lp:anybox.recipe.openerp/1.7 stable-recipe-61.cfg subdir=buildbot
+build-for = postgresql == 9.1
 build-category = mature
 
 [recipe-60-custom]
 # A buildout to test latest version of the recipe in an OpenERP 6.0 custom case
 # (stock server, bzr addons)
-buildout = standalone recipe-60.cfg
+buildout = bzr lp:anybox.recipe.openerp/trunk recipe-60.cfg subdir=buildbot
 build-for = postgresql == 8.4
 watch = bzr lp:anybox.recipe.openerp
 build-category = mature
@@ -37,39 +59,46 @@
 [recipe-61-custom]
 # A buildout to test latest version of the recipe in OpenERP 6.1 custom case
 # (bzr server and addons)
-buildout = standalone recipe-61.cfg
+buildout = bzr lp:anybox.recipe.openerp/trunk recipe-61.cfg subdir=buildbot
 build-for = postgresql == 9.1
 watch = bzr lp:anybox.recipe.openerp
 build-category = mature
 
 [stable-recipe-7.0]
 # A buildout to test latest stable revision of the recipe on OpenERP 7.0
-buildout = standalone stable-recipe-7.0.cfg
+buildout = bzr lp:anybox.recipe.openerp/1.7 stable-recipe-7.0.cfg subdir=buildbot
 build-for = postgresql >= 9.1
-watch = bzr lp:anybox.recipe.openerp
 
 [recipe-7.0]
 # A buildout to test latest revision of the recipe on OpenERP 7.0
-buildout = standalone recipe-7.0.cfg
+buildout = bzr lp:anybox.recipe.openerp/trunk recipe-7.0.cfg subdir=buildbot
 build-for = postgresql == 9.2
-watch = bzr lp:anybox.recipe.openerp
+post-buildout-steps = nose
+                      test-openerp
+nose.tests = anybox.recipe.openerp/tests_with_openerp --logging-level=INFO
 
 [recipe-trunk]
 # A buildout to test latest version of the recipe in OpenERP trunk
-buildout = standalone recipe-trunk.cfg
-build-for = postgresql >= 9.1
-watch = bzr lp:anybox.recipe.openerp
+buildout = bzr lp:anybox.recipe.openerp/trunk recipe-trunk.cfg subdir=buildbot
+build-for = postgresql > 9.2
 
 [recipe-61-nightly]
-# A buildout to test latest version of the recipe for OpenERP nightly build
-buildout = standalone recipe-nightly.cfg
-build-for = postgresql == 9.1
-watch = bzr lp:anybox.recipe.openerp
+# A buildout to test a latest revision of the recipe on an
+# OpenERP nightly build
+buildout = bzr lp:anybox.recipe.openerp recipe-nightly.cfg subdir=buildbot
+build-for = postgresql == 9.1
+build-category = experimental
+
+[stable-recipe-61-nightly]
+# A buildout to test latest stable revision of the recipe on an
+# OpenERP nightly build
+buildout = bzr lp:anybox.recipe.openerp/1.7 stable-recipe-nightly.cfg subdir=buildbot
+build-for = postgresql == 9.1
 build-category = experimental
 
 [recipe-61-latest]
 # A buildout to test latest version of the recipe for OpenERP nightly build
-buildout = standalone recipe-latest.cfg
+buildout = bzr lp:anybox.recipe.openerp recipe-latest.cfg subdir=buildbot
 build-for = postgresql == 9.1
 watch = bzr lp:anybox.recipe.openerp
 build-category = experimental
 
=== added file 'buildbot/base_recipe.cfg'
--- buildbot/base_recipe.cfg	1970-01-01 00:00:00 +0000
+++ buildbot/base_recipe.cfg	2014-02-06 07:42:46 +0000
@@ -0,0 +1,24 @@
+[buildout]
+parts = openerp
+find-links = http://download.gna.org/pychart/
+versions = versions
+extensions = gp.vcsdevelop
+vcs-extend-develop =
+    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/trunk#egg=anybox.recipe.openerp
+vcs-update = True
+
+[openerp]
+recipe = anybox.recipe.openerp:server
+options.xmlrpc = False
+options.xmlrpcs = False
+options.netrpc = False
+eggs = nose
+openerp_scripts = nosetests=nosetests command-line-options=-d
+
+[webclient]
+recipe = anybox.recipe.openerp:webclient
+version = 6.1-1
+
+[gtkclient]
+recipe = anybox.recipe.openerp:gtkclient
+version = nightly 6.1 latest
 
=== modified file 'buildbot/recipe-50.cfg'
--- buildbot/recipe-50.cfg	2013-08-04 10:35:20 +0000
+++ buildbot/recipe-50.cfg	2014-02-06 07:42:46 +0000
@@ -1,31 +1,14 @@
 [buildout]
-parts = openerp
-
-versions = versions
-find-links = http://download.gna.org/pychart/
-
-extensions = gp.vcsdevelop
-vcs-extend-develop =
-    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/trunk#egg=anyb
-vcs-update = True
+extends = base_recipe.cfg
 
 [openerp]
-recipe = anybox.recipe.openerp:server
 version = bzr lp:openobject-server/5.0 openerp-5.0 last:1
 addons = bzr lp:openobject-addons/5.0 addons-5.0 last:1
          bzr lp:openobject-addons/extra-5.0 addons-5.0-extra last:1 bzr-init=stacked-branch
-
 eggs = formencode
        pydns
 
-options.xmlrpc = False
-options.netrpc = True
-options.xmlrpcs = False
-xmlrpc_port = False
-xmlrpcs_port = False
-
 [gtkclient]
-recipe = anybox.recipe.openerp:gtkclient
 version = 5.0.16
 eggs = pytz
 
 
=== modified file 'buildbot/recipe-60-custom.cfg'
--- buildbot/recipe-60-custom.cfg	2013-08-02 15:52:01 +0000
+++ buildbot/recipe-60-custom.cfg	2014-02-06 07:42:46 +0000
@@ -1,12 +1,13 @@
 [buildout]
-parts = openerp
-extensions = gp.vcsdevelop 
-vcs-extend-develop =
-    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/trunk#egg=anybox.recipe.openerp
-vcs-update = True
-
-versions = versions
-find-links = http://download.gna.org/pychart/
+extends = base_recipe.cfg
+
+[openerp]
+version = 6.0.3
+addons = bzr lp:~anybox/openobject-addons/6.0.3-bugfix addons-6.0 last:1
+eggs =
+    formencode
+    pydns
+
 
 [versions]
 Babel = 0.9.6
@@ -40,13 +41,3 @@
 zc.buildout = 1.5.2
 zc.recipe.egg = 1.3.2
 
-[openerp]
-recipe = anybox.recipe.openerp:server
-eggs =
-    formencode
-    pydns
-
-version = 6.0.3
-addons = bzr lp:~anybox/openobject-addons/6.0.3-bugfix addons-6.0 last:1
-clean = true
-
 
=== modified file 'buildbot/recipe-60.cfg'
--- buildbot/recipe-60.cfg	2013-08-02 16:20:41 +0000
+++ buildbot/recipe-60.cfg	2014-02-06 07:42:46 +0000
@@ -1,22 +1,13 @@
 [buildout]
-parts = openerp
-extensions = gp.vcsdevelop
-versions = versions
-find-links = http://download.gna.org/pychart/
-#vcs-extend-develop =
-#    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/trunk#egg=anyb
-#vcs-update = True
-develop = /home/gracinet/openerp/recipe/anybox.recipe.openerp
+extends = base_recipe.cfg
+
 [openerp]
-recipe = anybox.recipe.openerp:server
 version = 6.0.4
 
 [webclient]
-recipe = anybox.recipe.openerp:server
 version = 6.0.4
 
 [gtkclient]
-recipe = anybox.recipe.openerp:gtkclient
 version = 6.0.4
 
 [versions]
 
=== modified file 'buildbot/recipe-61-custom.cfg'
--- buildbot/recipe-61-custom.cfg	2013-08-02 15:52:01 +0000
+++ buildbot/recipe-61-custom.cfg	2014-02-06 07:42:46 +0000
@@ -1,21 +1,11 @@
 [buildout]
-parts = openerp
-find-links = http://download.gna.org/pychart/
-versions = versions
-extensions = gp.vcsdevelop
-vcs-extend-develop =
-    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/trunk#egg=anybox.recipe.openerp
-vcs-update = True
+extends = base_recipe.cfg
 
 [openerp]
-recipe = anybox.recipe.openerp:server
+# TODO what is exactly custom here ?
 version = bzr lp:openobject-server/6.1 openerp-6.1 last:1
 addons = bzr lp:openobject-addons/6.1 addons-6.1 last:1
          bzr lp:openerp-web/6.1 addons-web last:1 subdir=addons
-clean = true
-options.xmlrpc = False
-options.xmlrpcs = False
-options.netrpc = False
 
 [versions]
 babel = 0.9.6
 
=== modified file 'buildbot/recipe-61.cfg'
--- buildbot/recipe-61.cfg	2013-08-02 16:20:41 +0000
+++ buildbot/recipe-61.cfg	2014-02-06 07:42:46 +0000
@@ -1,22 +1,13 @@
 [buildout]
-parts = openerp
-extensions = gp.vcsdevelop
-versions = versions
-find-links = http://download.gna.org/pychart/
-vcs-extend-develop =
-    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/trunk#egg=anyb
-vcs-update = True
+extends = base_recipe.cfg
 
 [openerp]
-recipe = anybox.recipe.openerp:server
 version = 6.1-1
 
 [webclient]
-recipe = anybox.recipe.openerp:server
 version = 6.1-1
 
 [gtkclient]
-recipe = anybox.recipe.openerp:gtkclient
 version = 6.1-1
 
 [versions]
 
=== modified file 'buildbot/recipe-7.0.cfg'
--- buildbot/recipe-7.0.cfg	2013-08-02 16:20:41 +0000
+++ buildbot/recipe-7.0.cfg	2014-02-06 07:42:46 +0000
@@ -1,21 +1,10 @@
 [buildout]
-parts = openerp
-find-links = http://download.gna.org/pychart/
-versions = versions
-extensions = gp.vcsdevelop
-vcs-extend-develop =
-    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/trunk#egg=anybox.recipe.openerp
-vcs-update = True
+extends = base_recipe.cfg
 
 [openerp]
-recipe = anybox.recipe.openerp:server
 version = bzr lp:openobject-server/7.0 openerp-7.0 last:1
 addons = bzr lp:openobject-addons/7.0 addons-7.0 last:1
          bzr lp:openerp-web/7.0 addons-web-7.0 last:1 subdir=addons
-clean = true
-options.xmlrpc = False
-options.xmlrpcs = False
-options.netrpc = False
 
 [versions]
 babel = 0.9.6
 
=== modified file 'buildbot/recipe-latest.cfg'
--- buildbot/recipe-latest.cfg	2013-08-02 16:20:41 +0000
+++ buildbot/recipe-latest.cfg	2014-02-06 07:42:46 +0000
@@ -1,22 +1,13 @@
 [buildout]
-parts = openerp
-extensions = gp.vcsdevelop
-versions = versions
-find-links = http://download.gna.org/pychart/
-vcs-extend-develop =
-    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/trunk#egg=anyb
-vcs-update = True
+extends = base_recipe.cfg
 
 [openerp]
-recipe = anybox.recipe.openerp:server
-version = nightly 6.1 20120217-003606
+version = nightly 6.1 latest
 
 [webclient]
-recipe = anybox.recipe.openerp:server
 version = 6.1-1
 
 [gtkclient]
-recipe = anybox.recipe.openerp:gtkclient
 version = nightly 6.1 latest
 
 [versions]
 
=== modified file 'buildbot/recipe-nightly.cfg'
--- buildbot/recipe-nightly.cfg	2013-08-02 16:20:41 +0000
+++ buildbot/recipe-nightly.cfg	2014-02-06 07:42:46 +0000
@@ -1,22 +1,13 @@
 [buildout]
-parts = openerp
-extensions = gp.vcsdevelop
-versions = versions
-find-links = http://download.gna.org/pychart/
-vcs-extend-develop =
-    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/trunk#egg=anyb
-vcs-update = True
+extends = base_recipe.cfg
 
 [openerp]
-recipe = anybox.recipe.openerp:server
 version = nightly 6.1 20120217-003606
 
 [webclient]
-recipe = anybox.recipe.openerp:server
 version = 6.1-1
 
 [gtkclient]
-recipe = anybox.recipe.openerp:gtkclient
 version = nightly 6.1 20120229-230351
 
 [versions]
 
=== modified file 'buildbot/recipe-trunk.cfg'
--- buildbot/recipe-trunk.cfg	2013-08-02 15:52:01 +0000
+++ buildbot/recipe-trunk.cfg	2014-02-06 07:42:46 +0000
@@ -1,21 +1,11 @@
 [buildout]
-parts = openerp
-find-links = http://download.gna.org/pychart/
-versions = versions
-extensions = gp.vcsdevelop
-vcs-extend-develop =
-    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/trunk#egg=anybox.recipe.openerp
-vcs-update = True
+extends = base_recipe.cfg
 
 [openerp]
 recipe = anybox.recipe.openerp:server
 version = bzr lp:openobject-server openerp-trunk last:1
 addons = bzr lp:openobject-addons addons-trunk last:1
          bzr lp:openerp-web addons-web-trunk last:1 subdir=addons
-clean = true
-options.xmlrpc = False
-options.xmlrpcs = False
-options.netrpc = False
 
 [versions]
 babel = 0.9.6
 
=== added file 'buildbot/stable-recipe-50.cfg'
--- buildbot/stable-recipe-50.cfg	1970-01-01 00:00:00 +0000
+++ buildbot/stable-recipe-50.cfg	2014-02-06 07:42:46 +0000
@@ -0,0 +1,4 @@
+[buildout]
+extends=recipe-50.cfg
+vcs-extend-develop =
+    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/1.7#egg=anyb
 
=== added file 'buildbot/stable-recipe-60.cfg'
--- buildbot/stable-recipe-60.cfg	1970-01-01 00:00:00 +0000
+++ buildbot/stable-recipe-60.cfg	2014-02-06 07:42:46 +0000
@@ -0,0 +1,4 @@
+[buildout]
+extends = recipe-60.cfg
+vcs-extend-develop =
+    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/1.7#egg=anyb
 
=== added file 'buildbot/stable-recipe-61.cfg'
--- buildbot/stable-recipe-61.cfg	1970-01-01 00:00:00 +0000
+++ buildbot/stable-recipe-61.cfg	2014-02-06 07:42:46 +0000
@@ -0,0 +1,4 @@
+[buildout]
+extends = recipe-61.cfg
+vcs-extend-develop =
+    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/1.7#egg=anyb
 
=== added file 'buildbot/stable-recipe-7.0.cfg'
--- buildbot/stable-recipe-7.0.cfg	1970-01-01 00:00:00 +0000
+++ buildbot/stable-recipe-7.0.cfg	2014-02-06 07:42:46 +0000
@@ -0,0 +1,4 @@
+[buildout]
+extends = recipe-7.0.cfg
+vcs-extend-develop =
+    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/1.7#egg=anybox.recipe.openerp
 
=== removed file 'buildbot/stable-recipe-7.0.cfg'
--- buildbot/stable-recipe-7.0.cfg	2013-09-07 12:04:02 +0000
+++ buildbot/stable-recipe-7.0.cfg	1970-01-01 00:00:00 +0000
@@ -1,42 +0,0 @@
-[buildout]
-# A buildout to test the support branch for the latest major version of the
-# recipe
-parts = openerp
-find-links = http://download.gna.org/pychart/
-versions = versions
-extensions = gp.vcsdevelop
-vcs-extend-develop =
-    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/1.7#egg=anybox.recipe.openerp
-vcs-update = True
-
-[openerp]
-recipe = anybox.recipe.openerp:server
-version = bzr lp:openobject-server/7.0 openerp-7.0 last:1
-addons = bzr lp:openobject-addons/7.0 addons-7.0 last:1
-         bzr lp:openerp-web/7.0 addons-web-7.0 last:1 subdir=addons
-clean = true
-options.xmlrpc = False
-options.xmlrpcs = False
-options.netrpc = False
-
-[versions]
-babel = 0.9.6
-PIL = 1.1.7
-pywebdav = 0.9.4.1
-PyXML = 0.8.4
-pyyaml = 3.10
-werkzeug = 0.8.3
-zsi = 2.0-rc3
-feedparser = 5.1.1
-gdata = 2.0.16
-lxml = 2.3.3
-psycopg2 = 2.4.4
-pydot = 1.0.28
-pyparsing = 1.5.6
-python-dateutil = 1.5
-python-ldap = 2.4.9
-python-openid = 2.2.5
-pytz = 2012b
-vatnumber = 1.0
-vobject = 0.8.1c
-xlwt = 0.7.3
 
=== added file 'buildbot/stable-recipe-nightly.cfg'
--- buildbot/stable-recipe-nightly.cfg	1970-01-01 00:00:00 +0000
+++ buildbot/stable-recipe-nightly.cfg	2014-02-06 07:42:46 +0000
@@ -0,0 +1,4 @@
+[buildout]
+extends = recipe-nightly.cfg
+vcs-extend-develop =
+    bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/1.7#egg=anyb
 
=== added directory 'doc'
=== added file 'doc/Makefile'
--- doc/Makefile	1970-01-01 00:00:00 +0000
+++ doc/Makefile	2014-02-06 07:42:46 +0000
@@ -0,0 +1,177 @@
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+PAPER         =
+BUILDDIR      = sphinx_build
+
+# User-friendly check for sphinx-build
+ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
+$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
+endif
+
+# Internal variables.
+PAPEROPT_a4     = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+# the i18n builder cannot share the environment and doctrees with the others
+I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html       to make standalone HTML files"
+	@echo "  dirhtml    to make HTML files named index.html in directories"
+	@echo "  singlehtml to make a single large HTML file"
+	@echo "  pickle     to make pickle files"
+	@echo "  json       to make JSON files"
+	@echo "  htmlhelp   to make HTML files and a HTML help project"
+	@echo "  qthelp     to make HTML files and a qthelp project"
+	@echo "  devhelp    to make HTML files and a Devhelp project"
+	@echo "  epub       to make an epub"
+	@echo "  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+	@echo "  latexpdf   to make LaTeX files and run them through pdflatex"
+	@echo "  latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
+	@echo "  text       to make text files"
+	@echo "  man        to make manual pages"
+	@echo "  texinfo    to make Texinfo files"
+	@echo "  info       to make Texinfo files and run them through makeinfo"
+	@echo "  gettext    to make PO message catalogs"
+	@echo "  changes    to make an overview of all changed/added/deprecated items"
+	@echo "  xml        to make Docutils-native XML files"
+	@echo "  pseudoxml  to make pseudoxml-XML files for display purposes"
+	@echo "  linkcheck  to check all external links for integrity"
+	@echo "  doctest    to run all doctests embedded in the documentation (if enabled)"
+
+clean:
+	rm -rf $(BUILDDIR)/*
+
+html:
+	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
+
+dirhtml:
+	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
+
+singlehtml:
+	$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
+	@echo
+	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
+
+pickle:
+	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
+	@echo
+	@echo "Build finished; now you can process the pickle files."
+
+json:
+	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
+	@echo
+	@echo "Build finished; now you can process the JSON files."
+
+htmlhelp:
+	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
+	@echo
+	@echo "Build finished; now you can run HTML Help Workshop with the" \
+	      ".hhp project file in $(BUILDDIR)/htmlhelp."
+
+qthelp:
+	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
+	@echo
+	@echo "Build finished; now you can run "qcollectiongenerator" with the" \
+	      ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
+	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/OpenERPbuildoutrecipe.qhcp"
+	@echo "To view the help file:"
+	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/OpenERPbuildoutrecipe.qhc"
+
+devhelp:
+	$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
+	@echo
+	@echo "Build finished."
+	@echo "To view the help file:"
+	@echo "# mkdir -p $$HOME/.local/share/devhelp/OpenERPbuildoutrecipe"
+	@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/OpenERPbuildoutrecipe"
+	@echo "# devhelp"
+
+epub:
+	$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
+	@echo
+	@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
+
+latex:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo
+	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
+	@echo "Run \`make' in that directory to run these through (pdf)latex" \
+	      "(use \`make latexpdf' here to do that automatically)."
+
+latexpdf:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo "Running LaTeX files through pdflatex..."
+	$(MAKE) -C $(BUILDDIR)/latex all-pdf
+	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+latexpdfja:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo "Running LaTeX files through platex and dvipdfmx..."
+	$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
+	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+text:
+	$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
+	@echo
+	@echo "Build finished. The text files are in $(BUILDDIR)/text."
+
+man:
+	$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
+	@echo
+	@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
+
+texinfo:
+	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+	@echo
+	@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
+	@echo "Run \`make' in that directory to run these through makeinfo" \
+	      "(use \`make info' here to do that automatically)."
+
+info:
+	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+	@echo "Running Texinfo files through makeinfo..."
+	make -C $(BUILDDIR)/texinfo info
+	@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
+
+gettext:
+	$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
+	@echo
+	@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
+
+changes:
+	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
+	@echo
+	@echo "The overview file is in $(BUILDDIR)/changes."
+
+linkcheck:
+	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
+	@echo
+	@echo "Link check complete; look for any errors in the above output " \
+	      "or in $(BUILDDIR)/linkcheck/output.txt."
+
+doctest:
+	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
+	@echo "Testing of doctests in the sources finished, look at the " \
+	      "results in $(BUILDDIR)/doctest/output.txt."
+
+xml:
+	$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
+	@echo
+	@echo "Build finished. The XML files are in $(BUILDDIR)/xml."
+
+pseudoxml:
+	$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
+	@echo
+	@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
 
=== added directory 'doc/apidoc'
=== added file 'doc/apidoc/anybox.recipe.openerp.rst'
--- doc/apidoc/anybox.recipe.openerp.rst	1970-01-01 00:00:00 +0000
+++ doc/apidoc/anybox.recipe.openerp.rst	2014-02-06 07:42:46 +0000
@@ -0,0 +1,75 @@
+anybox.recipe.openerp Package
+=============================
+
+:mod:`anybox.recipe.openerp` Package
+------------------------------------
+
+.. automodule:: anybox.recipe.openerp
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`base` Module
+------------------
+
+.. automodule:: anybox.recipe.openerp.base
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`devtools` Module
+----------------------
+
+.. automodule:: anybox.recipe.openerp.devtools
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`gtkclient` Module
+-----------------------
+
+.. automodule:: anybox.recipe.openerp.gtkclient
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`server` Module
+--------------------
+
+.. automodule:: anybox.recipe.openerp.server
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`testing` Module
+---------------------
+
+.. automodule:: anybox.recipe.openerp.testing
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`utils` Module
+-------------------
+
+.. automodule:: anybox.recipe.openerp.utils
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`webclient` Module
+-----------------------
+
+.. automodule:: anybox.recipe.openerp.webclient
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+Subpackages
+-----------
+
+.. toctree::
+
+    anybox.recipe.openerp.runtime
+    anybox.recipe.openerp.vcs
+
 
=== added file 'doc/apidoc/anybox.recipe.openerp.runtime.rst'
--- doc/apidoc/anybox.recipe.openerp.runtime.rst	1970-01-01 00:00:00 +0000
+++ doc/apidoc/anybox.recipe.openerp.runtime.rst	2014-02-06 07:42:46 +0000
@@ -0,0 +1,50 @@
+runtime Subpackage
+==================
+
+:mod:`runtime` Package
+----------------------
+
+.. automodule:: anybox.recipe.openerp.runtime
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`session` Module
+---------------------
+
+.. automodule:: anybox.recipe.openerp.runtime.session
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`upgrade` Module
+---------------------
+
+.. automodule:: anybox.recipe.openerp.runtime.upgrade
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`patch_openerp_v5` Module
+------------------------------
+
+.. automodule:: anybox.recipe.openerp.runtime.patch_openerp_v5
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`start_openerp` Module
+---------------------------
+
+.. automodule:: anybox.recipe.openerp.runtime.start_openerp
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`test_openerp` Module
+--------------------------
+
+.. automodule:: anybox.recipe.openerp.runtime.test_openerp
+    :members:
+    :undoc-members:
+    :show-inheritance:
 
=== added file 'doc/apidoc/anybox.recipe.openerp.vcs.rst'
--- doc/apidoc/anybox.recipe.openerp.vcs.rst	1970-01-01 00:00:00 +0000
+++ doc/apidoc/anybox.recipe.openerp.vcs.rst	2014-02-06 07:42:46 +0000
@@ -0,0 +1,59 @@
+vcs Subpackage
+==============
+
+:mod:`vcs` Package
+------------------
+
+.. automodule:: anybox.recipe.openerp.vcs
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`base` Module
+------------------
+
+.. automodule:: anybox.recipe.openerp.vcs.base
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`bzr` Module
+-----------------
+
+.. automodule:: anybox.recipe.openerp.vcs.bzr
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`git` Module
+-----------------
+
+.. automodule:: anybox.recipe.openerp.vcs.git
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`hg` Module
+----------------
+
+.. automodule:: anybox.recipe.openerp.vcs.hg
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`svn` Module
+-----------------
+
+.. automodule:: anybox.recipe.openerp.vcs.svn
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+:mod:`testing` Module
+---------------------
+
+.. automodule:: anybox.recipe.openerp.vcs.testing
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
 
=== added file 'doc/conf.py'
--- doc/conf.py	1970-01-01 00:00:00 +0000
+++ doc/conf.py	2014-02-06 07:42:46 +0000
@@ -0,0 +1,247 @@
+# -*- coding: utf-8 -*-
+#
+# OpenERP buildout recipe documentation build configuration file, created by
+# sphinx-quickstart on Wed Jul 24 18:32:19 2013.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys, os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+sys.path.insert(0, os.path.abspath('..'))
+# -- General configuration -----------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be extensions
+# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
+extensions = ['sphinx.ext.autodoc', 'sphinx.ext.doctest', 'sphinx.ext.todo', 'sphinx.ext.viewcode']
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['sphinx_templates']
+
+# The suffix of source filenames.
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8-sig'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = u'OpenERP buildout recipe'
+copyright = u'2011-2013, Anybox SAS'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = '1.8'
+# The full version, including alpha/beta/rc tags.
+release = '1.8.2-dev'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+exclude_patterns = ['sphinx_build']
+
+# The reST default role (used for this markup: `text`) to use for all documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+modindex_common_prefix = ['anybox.recipe.openerp.']
+
+# If true, keep warnings as "system message" paragraphs in the built documents.
+#keep_warnings = False
+
+
+# -- Options for HTML output ---------------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  See the documentation for
+# a list of builtin themes.
+html_theme = 'default'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further.  For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+#html_theme_path = []
+
+# The name for this set of Sphinx documents.  If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# A shorter title for the navigation bar.  Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+html_logo = 'sphinx_templates/logo.png'
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+html_favicon = 'sphinx_templates/favicon.ico'
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['sphinx_static']
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_domain_indices = True
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+#html_show_sourcelink = True
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+#html_show_sphinx = True
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+#html_show_copyright = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it.  The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# This is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = None
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'OpenERPbuildoutrecipedoc'
+
+
+# -- Options for LaTeX output --------------------------------------------------
+
+latex_elements = {
+# The paper size ('letterpaper' or 'a4paper').
+#'papersize': 'letterpaper',
+
+# The font size ('10pt', '11pt' or '12pt').
+#'pointsize': '10pt',
+
+# Additional stuff for the LaTeX preamble.
+#'preamble': '',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title, author, documentclass [howto/manual]).
+latex_documents = [
+  ('index', 'OpenERPbuildoutrecipe.tex', u'OpenERP buildout recipe Documentation',
+   u'Christophe Combelles, Georges Racinet', 'manual'),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+#latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = False
+
+# If true, show page references after internal links.
+#latex_show_pagerefs = False
+
+# If true, show URL addresses after external links.
+#latex_show_urls = False
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_domain_indices = True
+
+
+# -- Options for manual page output --------------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+    ('index', 'openerpbuildoutrecipe', u'OpenERP buildout recipe Documentation',
+     [u'Christophe Combelles, Georges Racinet'], 1)
+]
+
+# If true, show URL addresses after external links.
+#man_show_urls = False
+
+
+# -- Options for Texinfo output ------------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+#  dir menu entry, description, category)
+texinfo_documents = [
+  ('index', 'OpenERPbuildoutrecipe', u'OpenERP buildout recipe Documentation',
+   u'Christophe Combelles, Georges Racinet', 'OpenERPbuildoutrecipe', 'One line description of project.',
+   'Miscellaneous'),
+]
+
+# Documents to append as an appendix to all manuals.
+#texinfo_appendices = []
+
+# If false, no module index is generated.
+#texinfo_domain_indices = True
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#texinfo_show_urls = 'footnote'
+
+# If true, do not generate a @detailmenu in the "Top" node's menu.
+#texinfo_no_detailmenu = False
 
=== renamed file 'README.rst' => 'doc/configuration.rst'
--- README.rst	2013-09-07 11:43:18 +0000
+++ doc/configuration.rst	2014-02-06 07:42:46 +0000
@@ -1,5 +1,5 @@
-anybox.recipe.openerp
-=====================
+Configuration reference
+=======================
 
 This is a `Buildout <https://github.com/buildout/buildout>`_ recipe that can
 download, install and configure one or several OpenERP servers, web clients,
@@ -8,8 +8,6 @@
 with gunicorn deployment and an additional cron worker. It works under Linux
 and MacOs. It might work under Windows but it is untested.
 
-For a **quickstart** you can jump to the howto_ section.
-
 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
@@ -17,120 +15,167 @@
 buildout is gone. You never have to use administrative rights, except for
 build dependencies.
 
-.. contents::
-
-Recipes
-~~~~~~~
-
-You get 3 recipes at once. The recipe to use is the following:
-
-For the server::
+.. _buildout_conf_parts:
+
+The buildout configuration file and parts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The intents of this section is to highlights a few facts that we've
+found especially useful. People should refer to the
+`reference zc.buildout documentation
+<https://pypi.python.org/pypi/zc.buildout/2.2.1>`_
+and in particular to the `configuration file syntax
+<https://pypi.python.org/pypi/zc.buildout/2.2.1#configuration-file-syntax>`_
+(these links may have to be adapted for the version in use).
+
+
+Buildout configuration files are written almost in INI format, and
+always start with a ``buildout`` section::
+
+  [buildout]
+  parts = openerp
+
+The ``parts`` option specifies which parts to install by default if
+one runs ``bin/buildout`` with no explicit ``install`` directive.
+
+Parts directly correspond to sections of the configuration file, and
+must specify the recipe that's to be used::
+
+  [openerp]
+  recipe = anybox.recipe.openerp:server
+
+An extra dependency of the recipe gets required at runtime like this::
+
+  recipe = anybox.recipe.openerp[bzr]:server
+
+Command line
+------------
+The configuration file can be specified from the command line::
+
+  bin/buildout -c buildout.local.cfg
+
+Recipe options can be overridden from the command-line::
+
+  bin/buildout -c buildout.local.cfg openerp:clean=True openerp:xmlrpc_port=8169
+
+Parts that are not listed in the ``buildout`` configuration section
+can be explicitely installed::
+
+  bin/buildout install openerp funkload static-analysis
+
+.. _extends:
+
+Inheritance
+-----------
+
+A buildout configuration file can reference another one and change
+some options (note the ``+=`` notation that's not part of the INI format)::
+
+  [buildout]
+  extends = buildout.base.cfg
+
+  [openerp]
+  eggs += nose
+          coverage
+  with_devtools = True
+
+These extensions can be chained. This allows in particular project maintainers
+to separate the configuration options that are considered to be part
+of the project from those that depend on the server environment
+(ports, database hosts…)
+
+Default configuration
+---------------------
+
+If available, the settings from ``$HOME/.buildout/default.cfg`` always
+apply, as if it where the default value of the :ref:`extends <extends>` option.
+
+This is commonly used with the ``eggs-directory`` and
+:ref:`openerp-downloads-directory` options, because these amount to create a
+user-level cache.
+
+Finally, you may also use :ref:`extends <extends>` in ``default.cfg`` to point
+to a system-wide configuration file (useful to enforce
+policies at the organization or physical site level, such as local
+index servers, mirrors, etc.).
+
+
+OpenERP recipes
+~~~~~~~~~~~~~~~
+
+There are three different recipes bundled with
+``anybox.recipe.openerp``. The option line to put in your part (see
+:ref:`buildout_conf_parts`) is the following.
+
+Server
+------
+::
 
     recipe = anybox.recipe.openerp:server
 
-For the web client::
+.. note:: If you plan on using Launchpad's short Bazaar branch notation
+          (``lp:``), then you need to add the ``bzr`` extra-dependency::
+
+            recipe = anybox.recipe.openerp[bzr]:server
+
+Web client
+----------
+::
 
     recipe = anybox.recipe.openerp:webclient
 
-For the gtk client::
+GTK client
+----------
+::
 
     recipe = anybox.recipe.openerp:gtkclient
 
-Default options from zc.recipe.egg
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This recipe reuses the *zc.recipe.egg:scripts* recipe, so the options
-are the same (*eggs*, *interpreter*, etc.), and some changes, documented below.
-
-Consult the documentation here http://pypi.python.org/pypi/zc.recipe.egg
-
-The main useful ones are below:
-
-eggs
-----
-
-Starting from version 0.16 of the recipe, you don't need to put anything in
-this option by default. But you may specify additional eggs needed by addons,
-or just useful ones::
-
-    eggs = 
-        ipython
-        openobject-library
-
-scripts
--------
-.. note:: for scripts needing to call OpenERP internal API or to load
-          an OpenERP database prior to execution, check
-          ``openerp_scripts`` below.
-
-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)::
-
-        scripts =
-            change_tz
-
-In the current state, beware to *not* require the same script in different
-parts or rename them. See
-https://bugs.launchpad.net/anybox.recipe.openerp/+bug/1020967 for
-details.
-
-interpreter
------------
-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.
-
-
-Specific options
-~~~~~~~~~~~~~~~~
-
-The recipe also adds a few specific options:
+.. note:: from OpenERP 7.0 onwards, the web and gtk clients aren't
+          that useful anymore.
+
+Options for assembly and source management
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. _version:
 
 version
 -------
 
 Specifies the OpenERP version to use. It can be:
 
-The **version number** of an official OpenERP (server, web client or gtk client)::
-
-  version = 6.0.3
-
-A **custom download**::
-
-  version = url http://example.com/openerp.tar.gz
-
-An absolute or a relative **path**::
-
-  version = path /my/path/to/a/custom/openerp
-
-A custom **bzr, hg, git or svn** branch or repository. The syntax is the same
-as the `addons` option (see below)::
-
-  version = bzr lp:openobject-server/6.1 openerp61 last:1
-
-A **nightly** build::
-
-  version = nightly 6.1 20120814-233345
-
-or (dangerously unpinned version)::
-
-  version = nightly 6.1 latest
-
-or even more dangerous::
-
-  version = nightly trunk latest
-
+* The **version number** of an official OpenERP (server, web client or gtk client)::
+
+    version = 6.0.3
+
+* A **custom download**::
+
+    version = url http://example.com/openerp.tar.gz
+
+* An absolute or a relative **path**::
+
+    version = path /my/path/to/a/custom/openerp
+
+* A custom **bzr, hg, git or svn** branch or repository. The syntax is the same
+  as with the :ref:`addons` option::
+
+    recipe = anybox.recipe.openerp[bzr]:server
+    version = bzr lp:openobject-server/6.1 openerp61 last:1
+
+  .. note:: the ``[bzr]`` extra dependency declaration is useful for
+            resolution of the ``lp:`` address shortcuts.
+
+* A **nightly** build::
+
+    version = nightly 6.1 20120814-233345
+
+* or (dangerously unpinned version)::
+
+    version = nightly 6.1 latest
+
+*  or even more dangerous::
+
+     version = nightly trunk latest
+
+.. _addons:
 
 addons
 ------
@@ -139,6 +184,7 @@
 
 Example::
 
+  recipe = anybox.recipe.openerp[bzr]:server
   addons = local ../some/relative/path/for/custom_addons/
            local /some/other/absolute/path/for/custom_addons
            bzr lp:openobject-addons/trunk/    addons0 last:1
@@ -151,6 +197,10 @@
 addons, or a single addon. In that latter case, it will be actually
 placed one directory below.
 
+.. note:: the ``[bzr]`` extra-dependency declaration as showcased
+          above in the ``recipe`` line is necessary for
+          resolution of ``lp:`` launchpad address shortcuts.
+
 .. warning::
 
    Never name one of these addons directory simply ``addons``. It
@@ -159,15 +209,17 @@
 
 For remote repositories, the syntax is:
 
-``TYPE  URL  DESTINATION  REVISION  [OPTIONS]``
-
-* *TYPE* can be ``bzr``, ``hg``, ``git`` or ``svn``
-* *URL* is any URL scheme supported by the versionning tool
-* *DESTINATION* is the local directory that will be created (relative or absolute)
-* *REVISION* is any version specification supported (revision, tag, etc.)
-* *OPTIONS* take the form ``name=value``. Currently the ``subdir``
-  option is recognized. If used, the given subdirectory of the
-  repository is registered as an addons directory.
+    ``TYPE  URL  DESTINATION  REVISION  [OPTIONS]``
+
+with the following semantics:
+
+:TYPE: one of ``bzr``, ``hg``, ``git`` or ``svn``
+:URL: is any URL scheme supported by the versionning tool
+:DESTINATION: is the local directory that will be created (relative or absolute)
+:REVISION: is any version specification supported (revision, tag, etc.)
+:OPTIONS: each one takes the form ``name=value``. No whitespace is
+          allowed inside an option, and no escaping is
+          implemented.
 
 Repositories are updated on each build according to the specified
 revision. You must be careful with the revision specification.
@@ -176,32 +228,59 @@
 specified revision is performed, if the VCS allows it (Subversion does
 not).
 
-.. note:: An additional option is supported for bzr. **'bzr-init'**
-          defines the way the bzr branch
-          is initialized for addons or server declared with a bzr
-          repository path.
-
-          Possible values:
-
-          branch (default)
-            Working copy initialized with the command
-            ``bzr branch url ...``
-          stacked-branch
-           Working copy initialized with the command
-           ``bzr branch --stacked url ...``
-
-          lightweight-checkout
-            Working copy initialized with the command
-            ``bzr checkout --lightweight url ...``
+The ``subdir`` addons option
+````````````````````````````
+
+The ``subdir`` option, if used, makes the recipe use the given
+subdirectory of the repository as the addons directory.
+A very common example is the line for standard web addons from bzr::
+
+   bzr lp:openerp-web/7.0 openerp-web last:1 subdir=addons
+
+The ``bzr-init`` addons option
+``````````````````````````````
+**'bzr-init'** defines the way the bzr branch
+is initialized for addons or server declared with a bzr
+repository path.
+
+.. note:: new in version 1.7.0
+
+Possible values:
+
+:branch (default):  Working copy initialized with the command
+                    ``bzr branch url ...``
+
+:stacked-branch:  Working copy initialized with the command
+                  ``bzr branch --stacked url ...``
+:lightweight-checkout: Working copy initialized with the command
+                       ``bzr checkout --lightweight url ...``
+
+.. _eggs:
+
+eggs
+----
+This option behaves like the identically named one of the most common
+`zc.recipe.egg <https://pypi.python.org/pypi/zc.recipe.egg>`_.
+
+Starting from version 0.16 of the recipe, you don't need to put anything in
+this option by default: the recipe is supposed to add all needed
+dependencies for OpenERP by itself, but you have to specify additional
+eggs needed by addons, or just useful ones::
+
+    eggs = ipython
+           python-ldap
+           openobject-library
+
+.. _revisions:
 
 revisions
 ---------
 
 This option allows to further precise what has been specified through
-the  ``addons`` and ``version`` options by fixing VCS revisions.
+the  :ref:`addons` and :ref:`version` options by fixing VCS revisions.
 
-The main use-case it to apply it in an extension buildout
-configuration file::
+The main use-case it to apply it in an :ref:`extension buildout
+configuration file <extends>`::
 
    [buildout]
    extends = base.cfg
@@ -211,7 +290,7 @@
                addons-openerp 7109
 
 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
+filesystem path, as in the :ref:`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.
 
@@ -223,278 +302,196 @@
 * freezing satisfactory revisions in a release process (the recipe can
   do that automatically for you, see ``freeze-to`` option below).
 
+.. _clean:
+
 clean
 -----
 
 If set to true, this option will clean remove python object files from
-the main server part and addons before any update or install.
+the main server part and addons before any update or install, and
+perform relevant VCS idea of "clean, purge".
+
+.. warning:: developers can lose their uncommitted work with this option.
+
+             This option is not meant for developer setups, rather for
+             deployment and continuous integration. To avoid making a
+             dedicated buildout configuration for you CI bot, just add
+             it on the command-line.
 
 Note that tarball downloads get re-extracted afresh in any case.
 
-openerp_scripts
----------------
-
-Introduction and use-cases
-``````````````````````````
-This option lets you install console scripts provided by any of the loaded eggs,
-so that they can access to OpenERP internals and load databases.
-Some interesting use-cases:
-
-* specific batch jobs
-* introspection tools
-* general-purposes test launchers that don't have any knowledge of
-  OpenERP specifics
-* actually, the main startup scripts themselves (with a default
-  configuration, of course)
-
-Usage
-`````
-This multiline option is similar to the classical ``scripts`` options
-of ``zc.recipe.eggs:scripts``. It lets you ask for installation of
-console scripts provided by the various Python distribution involved
-in the buildout part (including OpenERP itself).
-
-The built console scripts can import all the involved Python
-distributions, and have access to a ``session`` object, to issue
-OpenERP native calls (see
-``interpreter_name`` option below for details on how to use it).
-
-One has to register exactly one console script per line.
-
-As it is the case with ``scripts``, one actually specifies the name of the
-entry point to use (we are all used to that entry point being the name
-of the resulting script, because that's what ``setup.py install`` does).
-
-Suppose there is a distribution ``my.package`` with the following lines in
-its ``setup.py``::
-
-      entry_points="""
-
-      [console_scripts]
-      my = my.package.main:run
-      """
-
-Now the following configuration extract builds a script called
-``my_openerp1``, that can access ``session``::
-
-  [openerp1]
-  (...)
-  openerp_scripts = my
-
-To control the script name, just do, e.g,::
-
-  [openerp1]
-  (...)
-  openerp_scripts = my=my_script
-
-This will build it as ``bin/my_script``.
-
-Command-line options and test launchers
-```````````````````````````````````````
-
-If ``my.package`` is meant to do OpenERP heavy-lifting, then surely it
-will provide a powerful command-line parsing. e.g., to let the end user chose
-the database on which to work, etc.
-
-Sometimes, however, the script itself has no knowledge of OpenERP at
-all, but still must run after a database has been fully initialized.
-The main use case for this is test launchers, such as
-`nose <https://nose.readthedocs.org/en/latest/>`_ or simply ``unit2``.
-For these, the recipe has a facility to rewrap the script and add some further
-command-line options.
-
-In this example, we build ``unit2``, the launcher that comes with
-``unittest2``, and wrap it to add the database option::
-
-  [openerp]
-  (...)
-  openerp_scripts = unit2 command-line-options=-d
-
-You may then run it this way::
-
-   bin/unit2_openerp -d unit-tests-db -- discover some/addon
-
-Notice how ``--`` is used to separate the ``-d`` or
-any recipe-related options from the options expected by the script itself.
-
-If one wishes to run the tests with ``nose``, one has further to
-require it. In the following example, we also ask for the ``coverage``
-package::
-
-  [openerp]
-  (...)
-  eggs = nose
-         coverage
-  openerp_scripts = nosetests command-line-options=-d
-
-Here's our test run with coverage and pdb post-mortem::
-
-  bin/nosetests-openerp -d unit-tests-db -- --nologcapture \
-           --with-coverage --pdb \
-           some/addon/tests/test_one.py
-
-Main startup scripts
-````````````````````
-The recipe will in all cases build OpenERP startup scripts, according to other
-configuration options (gunicorn, tests etc.). These are
-actually special cases of the scripts controlled via ``openerp_scripts``.
-
-This allows you (for now) to control the names. For instance, to
-replace ``bin/start_openerp`` with ``bin/oerp``, just do::
-
-  [openerp]
-  (...)
-  openerp_scripts = openerp_starter=oerp
-
-Here's the list of currently available internal entry points. For
-these, the ``command-line-options`` modifier has no effect.
-
-:openerp_starter: main OpenERP startup script (dynamically added
-                  behing the scenes by the recipe)
-:openerp_tester: uniform script to start OpenERP, launch all tests and
-                 exit. This can be achieved with the main startup
-                 scripts, but options differ among OpenERP versions.
-                 (also dynamically added behind the scenes).
-:openerp_cron_worker: entry point for the cron worker script that gets
-                      built for gunicorn setups.
-:oe: entry point declared by ``openerp-command`` and used by the recipe.
-:gunicorn: entry point declared by ``gunicorn`` and used by the recipe.
+.. _openerp_options:
+
+OpenERP options
+~~~~~~~~~~~~~~~
+
+With the OpenERP buildout recipes, OpenERP options are managed
+directly from the buildout file (usually
+``buildout.cfg``) from the part.
+
+The OpenERP configuration files are generated by OpenERP itself in the directory
+specified by ``etc-directory``, which defaults to the `etc` directory under your
+buildout directory.
+
+The settings of the OpenERP configuration files are specified using a
+dotted notation in which the fist segment is the name of the
+corresponding section of the OpenERP config file and the second is the
+option name.
+
+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 section of the buildout file.  If a setting 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::
+
+  options.xmlrpc_port = 8069
+  options.additional_option = "foobar"
+
+It will end-up in the server configuration as::
+
+  [options]
+  xmlrpc_port = 8069
+  additional_option = "foobar"
+
+For the web client you can specify the port and company url with::
+
+  global.server.socket_port = 8080
+  openerp-web.company.url = 'http://anybox.fr'
+
+It will modify the corresponding web client config::
+
+  [global]
+  server.socket_port = 8080
+
+  [openerp-web]
+  company.url = 'http://anybox.fr'
+
+.. note:: Buildout :ref:`configuration inheritance <extends>` is
+          especially useful to manage the separation between a
+          reusable buildout configuration and local settings.
+
+.. note:: Note that for security reasons, the superadmin password is not set by
+    default. If you want databases to be manageable through the UI,
+    you may either explicitely set that password in the buildout part
+    configuration or even set it temporarily in the
+    ``etc/openerp.conf`` file.
+
+
+Options for executables generation and serving
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. _script_name:
 
 script_name
 -----------
 
 .. warning:: as of version 1.7.0, this option is deprecated because of its
-             redundancy with ``openerp_scripts``.
-
-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
+             redundancy with :ref:`openerp_scripts`.
+
+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 ::
 
-    script_name = start_erp  
-
-interpreter_name
-----------------
-
-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.
-
-startup_delay
--------------
-
-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 ::
-
-    startup_delay = 3
-
-with_devtools
--------------
-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
-<http://pypi.python.org/pypi/anybox.testing.datetime>`_ (allows to
-cheat with system time).
-
-test_script_name
-----------------
-.. warning:: as of version 1.7.0, this option is deprecated because of its
-             redundancy with ``openerp_scripts``.
-
-If the ``with_devtools`` is set to True, the recipe will create a
-test script, which is named by default ``test_<part_name>``. You may
-override the name in the configuration as in the following example::
-
-  test_script_name = test_erp
-
-The test script takes the same arguments as the regular startup
-script::
-
-  bin/test_openerp --help
-  bin/test_openerp -d test_db -i purchase,sale
-
-At the time of this writing, all this script does compared to the
-regular startup script is to bring uniformity across OpenERP versions
-by tweaking options internally.
-
-base_url
---------
-
-URL from which to download official and nightly versions
-(assuming the archive filenames are constistent with those in
-OpenERP download server). This is a basic mirroring capability::
-
-    base_url = http://download.example.com/openerp/
-
-openerp-downloads-directory
----------------------------
-
-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.
-
-Example::
-
-    [buildout]
-    openerp-downloads-directory = /home/user/.buildout/openerp-downloads
+    script_name = start_erp
+
+
+.. _openerp_scripts:
+
+openerp_scripts
+---------------
+This option lets you install console scripts provided by any of the loaded eggs,
+so that they can access to OpenERP internals and load databases.
+
+.. note:: new in version 1.7.0
+
+Here we describe the format of the option only.
+For explanation about what it means and how to use it, please refer to
+:doc:`/scripts`.
+
+The option is multiline. Each line specifies exactly one
+script, and must respect the following format:
+
+  ``ENTRY_POINT_NAME[=WISHED_SCRIPT_NAME] [MODIFIER [MODIFIER […]]]``
+
+Each modifier takes the ``MODIFIER_NAME=MODIFIER_VALUE`` form.
+No whitespace is allowed in modifiers, entry point, nor produced script names.
+
+Here's the list of currently available modifiers, with links inside :doc:`the
+dedicated chapter about OpenERP scripts </scripts>`).
+
+:command-line-options: :ref:`command_line_options`
+:arguments: :ref:`arguments_session`
+
+Full example::
+
+  openerp_scripts = my_script arguments=session
+                    my_other_script=actual-script-name arguments=3,session
+                    nosetests=nosetests command-line-options=-d
+
+
+.. _upgrade_script_name:
+
+upgrade_script_name
+-------------------
+
+This option lets you specify the wished name for the upgrade script.
+The default value is ``upgrade_<part_name>``.
+
+.. note:: new in version 1.8.0.
+
+          We are actually not sure to keep that option, since it's
+          redundant with :ref:`openerp_scripts`.
+
+
+.. _upgrade_script:
+
+upgrade_script
+--------------
+
+.. note:: new in version 1.8.0
+
+This option lets you specify a source (``.py``) file and a callable
+defined in that file to perform database upgrades. The default value
+is::
+
+  upgrade_script = upgrade.py run
+
+If the specified source file doest not exist, the recipe will
+initialize it with a simple and meaningful sample content, consistent
+with the default value above.
+
+If you want *not* to have an upgrade script, just override this option
+with a blank value::
+
+  upgrade_script =
+
+See the full :ref:`upgrade_scripts` documentation to learn more
+about upgrade scripts.
+
+.. note:: new in version 1.8.0
+
+
+.. _gunicorn:
 
 gunicorn
 --------
 
-Gunicorn integration is only supported on OpenERP >= 6.1.
+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
+``proxied``. Any value is suitable for OpenERP ≥ 7
 
 Proxied mode
 ````````````
@@ -503,7 +500,7 @@
 
     gunicorn = proxied
 
-This behaviour has been kept for OpenERP >= 7 to keep
+This behaviour has been kept for OpenERP ≥ 7 to keep
 backwards compatibility, but the option is now superseded by the
 general ``proxy_mode`` option of the server. In the buildout context,
 that'd be::
@@ -552,25 +549,24 @@
 allows for graceful restarts (use this for minor changes only).
 
 
+.. _openerp_command_name:
+
 openerp_command_name
 --------------------
-.. warning:: as of version 1.7.0, this option is deprecated, check
-   ``openerp_scripts`` for more details.
+.. warning:: as of version 1.7.0, this option is deprecated because of
+             its redundancy with :ref:`openerp_scripts`.
 
 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.
+It is currently enabled if the :ref:`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::
-
-  [buildout]
-  extensions = gp.vcsdevelop
-  vcs-extend-develop = bzr+http://bazaar.launchpad.net/openerp/openerp-command#egg=openerp-command
+distribution, which is not on PyPI as of this writting, but comes
+bundled with the current OpenERP trunk (believed to be the future
+OpenERP 8).
 
 As for other scripts, you can control its name of the produced script, e.g::
 
@@ -580,11 +576,226 @@
 ``oe`` is the classical name for this script outside of the realm of
 this buildout recipe.
 
+.. note:: ``openerp-command`` has first been introduced as a separate
+          project while OpenERP 7.0 was in development stage. People
+          wanting to use it with OpenERP 7.0 can still grab it from
+          Launchpad with the ``gp.vcsdevelop`` extension::
+
+            [buildout]
+            extensions = gp.vcsdevelop
+            vcs-extend-develop = bzr+http://bazaar.launchpad.net/openerp/openerp-command@419#egg=openerp-command
+
+          The latest Launchpad revision is actually the final removal,
+          done at the time where it's been included in
+          ``lp:openobject-server``.
+
+
 .. warning::
 
-  Do not use to launch production servers, especially in an automatic
-  way, openerp-command is really unstable and that may damage your
-  installation.
+  On OpenERP 7, do not use to launch production servers, especially in
+  an automatic way, ``openerp-command`` is really unstable and that
+  may damage your installation.
+
+
+
+scripts
+-------
+.. note:: This option is useful for general purpose scripts
+          only. For scripts related to OpenERP, see
+          :doc:`/scripts`, and the :ref:`openerp_scripts` option.
+
+This option controls the generation of console scripts declared by the
+various involved Python distributions (either directly required with
+the :ref:`eggs` option, or by dependency).
+
+By default, no such script is generated, but you may specify some
+according to your needs, with the same semantics as in ``zc.recipe.egg``.
+
+        scripts = change_tz
+
+In the current state, beware to *not* require the same script in different
+parts or rename them. See
+https://bugs.launchpad.net/anybox.recipe.openerp/+bug/1020967 for
+details.
+
+
+.. _startup_delay:
+
+startup_delay
+-------------
+
+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 ::
+
+    startup_delay = 3
+
+Options for development, QA and introspection
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. _with_devtools:
+
+with_devtools
+-------------
+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
+<http://pypi.python.org/pypi/anybox.testing.datetime>`_ (allows to
+cheat with system time).
+
+
+.. _test_script_name:
+
+test_script_name
+----------------
+.. warning:: as of version 1.7.0, this option is deprecated because of its
+             redundancy with :ref:`openerp_scripts`.
+
+If the ``with_devtools`` is set to True, the recipe will create a
+test script, which is named by default ``test_<part_name>``. You may
+override the name in the configuration as in the following example::
+
+  test_script_name = test_erp
+
+The test script takes the same arguments as the regular startup
+script::
+
+  bin/test_openerp --help
+  bin/test_openerp -d test_db -i purchase,sale
+
+At the time of this writing, all this script does compared to the
+regular startup script is to bring uniformity across OpenERP versions
+by tweaking options internally.
+
+*As of version 1.8.2*, the ``--install-all`` additional option will be
+expanded on-the-fly as ``-i`` on all available modules (don't confuse
+with ``-i all``: the latter is equivalent to ``-i base``).
+
+
+.. _interpreter_name:
+
+interpreter_name
+----------------
+
+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 =
+
+If you want to wrap a python script with such session objects, read
+:doc:`/scripts` and especially :ref:`arguments_session`.
+See also :ref:`openerp_scripts`.
+
+.. note:: this facility is new in version 1.6.0, and tested with
+          OpenERP ≥ 6.1 only for now.
+
+
+interpreter
+-----------
+With the ``gtkclient`` and ``webclient`` recipes,
+this behauves like the `interpreter` option of `zc.recipe.egg`: it
+gives you a Python interpreter in the ``bin`` subdirectory of the buildout::
+
+    interpreter = erp_python
+
+With the ``server`` recipe, the ``interpreter`` option will be ignored,
+because this recipe always creates an interpreter with preloaded objects to
+bootstrap openerp, and these depend on the configuration.
+Check :ref:`interpreter_name` for more details.
+
+
+
+
+Options for download and caching strategies
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Let us start by listing a few global buildout options (to be put in
+the ``[buildout]`` section), whose scope is much larger than the
+OpenERP recipe.
+
+:eggs-directory: control where eggs are stored after download and/or
+                 build and reciprocally acts as a cache.
+:index: specifies where to get informations about distributions not found in
+        ``eggs-directory``.
+:find-links: direct URLs to look for distributions
+:allow-hosts: white list of URL patterns allowed for distributions
+              download. Great to exclude the numerous useless sites
+              that setuptools may want to crawl and which tend to
+              break each time a new version gets referenced on PyPI.
+
+The OpenERP recipes define a few more.
+
+
+.. _base_url:
+
+base_url
+--------
+This option is local to the *part*.
+
+URL from which to download official and nightly versions
+(assuming the archive filenames are constistent with those in
+OpenERP download server). This is a basic mirroring capability::
+
+    base_url = http://download.example.com/openerp/
+
+
+.. _openerp-downloads-directory:
+
+openerp-downloads-directory
+---------------------------
+This is an option for the ``[buildout]`` section
+
+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.
+
+Example::
+
+    [buildout]
+    openerp-downloads-directory = /home/user/.buildout/openerp-downloads
+
+
+
+Options for release and packaging
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. note:: release and packaging should be provided by dedicated
+          executables, not by options. These options should disappear
+          at some point between 1.8 and 1.9 versions.
+
+.. _freeze-to:
 
 freeze-to
 ---------
@@ -613,7 +824,7 @@
     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
+with notably an ``openerp-server-1`` part having a :ref:`revisions` option that
 freezes everything.
 
 For configurations with several openerp related parts, you can freeze
@@ -641,22 +852,25 @@
 .. warning:: currently ``freeze-to`` cannot fix eggs versions related
              to non-openerp parts.
 
+.. _freeze-allow-picked-versions:
+
 freeze-allow-picked-versions
 ----------------------------
 
-This option is to be used in conjunction with ``freeze-to``. If set to
+This option is to be used in conjunction with :ref:`freeze-to`. If set to
 ``False``, it will add ``allow-picked-versions = false``
 for ``zc.buildout`` versions that support this flag.
 
 .. warning:: in the current state of things, this can cause problems
-             if you have non-openerp parts (see warning in ``freeze-to``
-             documentation).
+             if you have non-openerp parts (see the various warnings
+             in :ref:`freeze-to`)
 
+.. _extract-downloads-to:
 
 extract-downloads-to
 --------------------
 
-Following the same kind of logic as ``freeze-to``, this option allows
+Following the same kind of logic as :ref:`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.
@@ -685,8 +899,8 @@
 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``).
+The ``extract-downloads-to`` option can be used for several parts
+with the same target directory (same as :ref:`freeze-to`).
 
 Furthermore, a default ``freeze-to`` is issued, producing a buildout
 configuration called ``extracted_from.cfg`` in the target directory,
@@ -698,317 +912,3 @@
 same rules with respect to uncommitted changes.
 
 Python distributions managed with ``gp.vcsdevelop`` are taken into account.
-
-
-OpenERP options
----------------
-
-You can define OpenERP options directly from the buildout file (usually
-``buildout.cfg``) in the recipe section.
-The OpenERP configuration files are generated by OpenERP itself in the directory
-specified by ``etc-directory`` which defaults to the `etc` directory under your
-buildout directory.
-The settings of the OpenERP configuration files can be controlled using a
-dotted notation prefixed by 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 section of the buildout file.  If a setting 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::
-
-  options.xmlrpc_port = 8069
-  options.additional_option = "foobar"
-
-It will end-up in the server config as::
-
-  [options]
-  xmlrpc_port = 8069
-  additional_option = "foobar"
-
-For the web client you can specify the company url with::
-
-  global.server.socket_port = 8080
-  openerp-web.company.url = 'http://anybox.fr'
-
-It will modify the corresponding web client config::
-
-  [global]
-  server.socket_port = 8080
-
-  [openerp-web]
-  company.url = 'http://anybox.fr'
-
-
-.. note:: Note that for security reason, the superadmin password is not set by
-    default. If you want to create a database you should temporary set it manually
-    in the etc/openerp.conf file
-
-
-
-.. _howto:
-
-How to create and bootstrap a buildout
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-To create a buildout and run the build, you just need **1 file** and **2 commands**:
-
-- Create a single ``buildout.cfg`` file.
-- Be sure you installed all your build dependencies
-- Bootstrap the buildout with: ``python bootstrap.py``
-- Run the build with: ``bin/buildout``
-
-The same with more details below :
-
-Creating the buildout
----------------------
-
-Create a ``buildout.cfg`` file in an empty directory, containing the
-configuration of the `example 6.1`_ section.
-
-.. _dependencies:
-
-Installing build dependencies
------------------------------
-
-You basically need typical development tools needed to build all the Python
-dependency eggs of OpenERP. You can do this by yourself with your system or
-Linux distribution.
-
-Or if you're using a Debian system, we provide a single dependency package you
-can use to install all dependencies in one shot:
-
-Add the following line in your ``/etc/apt/sources.list``::
-
-  deb http://apt.anybox.fr/openerp common main
-
-Install the dependency package::
-
-  $ sudo aptitude update 
-  $ sudo aptitude install openerp-server-system-build-deps
-
-You can uninstall this package with `aptitude` after the build to
-automatically remove all un-needed dependencies, but you need to
-install *run dependencies* before that ::
-
-  $ sudo aptitude install openerp-server-system-run-deps
-  $ sudo aptitude remove openerp-server-system-build-deps
-
-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.
-
-Bootstrapping the buildout
---------------------------
-
-Bootstrapping the buildout consists in creating the basic structure of the buildout, and installing buildout itself in the directory.
-
-The easiest and recommended way to bootstrap is to use a ``bootstrap.py`` script::
-
-  $ wget https://raw.github.com/buildout/buildout/master/bootstrap/bootstrap.py
-  $ python bootstrap.py
-
-As an alternative and more complicated solution, you may also bootstrap by
-creating a virtualenv, installing zc.buildout, then run the bootstrap::
-
-  $ virtualenv sandbox
-  $ sandbox/bin/pip install zc.buildout
-  $ sandbox/bin/buildout bootstrap
-
-Running the build
------------------
-
-Just run ::
-
-  $ bin/buildout
-
-Starting OpenERP
-----------------
-
-Just run ::
-
-  $ bin/start_openerp
-
-
-.. _example 6.1:
-
-Example OpenERP 6.1 buildout
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Here is a very simple example for a latest OpenERP 6.1 nightly and a
-custom addon hosted on Bitbucket:
-
-::
-
-    [buildout]
-    parts = openerp 
-    versions = versions
-    find-links = http://download.gna.org/pychart/
-    
-    [openerp]
-    recipe = anybox.recipe.openerp:server
-    # replace '6.1' with 'trunk' to get a 7.0 current nightly:
-    version = nightly 6.1 latest
-    addons = hg https://bitbucket.org/anybox/anytracker addons-at default
-
-    [versions]
-    MarkupSafe = 0.15
-    Pillow = 1.7.7
-    PyXML = 0.8.4
-    babel = 0.9.6
-    feedparser = 5.1.1
-    gdata = 2.0.16
-    lxml = 2.3.3
-    mako = 0.6.2
-    psycopg2 = 2.4.4
-    pychart = 1.39
-    pydot = 1.0.28
-    pyparsing = 1.5.6
-    python-dateutil = 1.5
-    python-ldap = 2.4.9
-    python-openid = 2.2.5
-    pytz = 2012b
-    pywebdav = 0.9.4.1
-    pyyaml = 3.10
-    reportlab = 2.5
-    simplejson = 2.4.0
-    vatnumber = 1.0
-    vobject = 0.8.1c
-    werkzeug = 0.8.3
-    xlwt = 0.7.3
-    zc.buildout = 1.5.2
-    zc.recipe.egg = 1.3.2
-    zsi = 2.0-rc3
-
-
-.. note:: 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.
-
-
-Example OpenERP 6.0 buildout
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Here is a sample buildout with version specification, 2 OpenERP servers (with
-one using the latest 6.0 branch on the launchpad) using only NETRPC and
-listening on 2 different ports, and 2 web clients::
-
-    [buildout]
-    parts = openerp1 web1 openerp2 web2
-    #allow-picked-versions = false
-    versions = versions
-    find-links = http://download.gna.org/pychart/
-    
-    [openerp1]
-    recipe = anybox.recipe.openerp:server
-    version = 6.0.3
-    options.xmlrpc = False
-    options.xmlrpcs = False
-    
-    [web1]
-    recipe = anybox.recipe.openerp:webclient
-    version = 6.0.3
-    
-    [openerp2]
-    recipe = anybox.recipe.openerp:server
-    version = bzr lp:openobject-server/6.0 openobject-server-6.x last:1
-
-    options.xmlrpc = False
-    options.xmlrpcs = False
-    options.netrpc_port = 8170
-    
-    [web2]
-    recipe = anybox.recipe.openerp:webclient
-    version = 6.0.3
-    global.openerp.server.port = '8170'
-    global.server.socket_port = 8180
-    
-    [versions]
-    MarkupSafe = 0.15
-    Pillow = 1.7.7
-    anybox.recipe.openerp = 0.9
-    caldav = 0.1.10
-    collective.recipe.cmd = 0.5
-    coverage = 3.5
-    distribute = 0.6.25
-    feedparser = 5.0.1
-    lxml = 2.1.5
-    mako = 0.4.2
-    nose = 1.1.2
-    psycopg2 = 2.4.2
-    pychart = 1.39
-    pydot = 1.0.25
-    pyparsing = 1.5.6
-    python-dateutil = 1.5
-    pytz = 2012b
-    pywebdav = 0.9.4.1
-    pyyaml = 3.10
-    reportlab = 2.5
-    vobject = 0.8.1c
-    z3c.recipe.scripts = 1.0.1
-    zc.buildout = 1.5.2
-    zc.recipe.egg = 1.3.2
-    Babel = 0.9.6
-    FormEncode = 1.2.4
-    simplejson = 2.1.6
-
-
-Other sample buildouts
-~~~~~~~~~~~~~~~~~~~~~~
-
-Here are a few ready-to-use buildouts:
-
-(Be sure to install system dependencies_ first)
-
-OpenERP with the development branches of the Magento connector addons::
-
-  $ hg clone https://bitbucket.org/anybox/openerp_connect_magento_buildout
-  $ cd openerp_connect_magento_buildout
-  $ python bootstrap.py
-  $ bin/buildout
-  $ bin/start_openerp
-
-OpenERP with the development branches of the Prestashop connector addons::
-
-  $ hg clone https://bitbucket.org/anybox/openerp_connect_prestashop_buildout
-  $ cd openerp_connect_prestashop_buildout
-  $ python bootstrap.py
-  $ bin/buildout
-  $ bin/start_openerp
-
-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
-<http://pypi.python.org/pypi/anybox.recipe.openerp>`_), and are
-continuously tested in the
-`anybox buildbot <http://buildbot.anybox.fr/>`_ which is powered by
-`anybox.buildbot.openerp <http://pypi.python.org/pypi/anybox.buildbot.openerp>`_.
-
-
-Contribute
-~~~~~~~~~~
-
-Authors:
-
- * Christophe Combelles
- * Georges Racinet
-
-Contributors:
-
- * Jean-Sébastien Suzanne
- * Yannick Vaucher
- * Jacques-Etienne Baudoux
- * Laurent Mignon
- * Leonardo Pistone
-
-The primary branch is on the launchpad:
-
- * Code repository and bug tracker: https://launchpad.net/anybox.recipe.openerp
- * PyPI page: http://pypi.python.org/pypi/anybox.recipe.openerp
-
-Please don't hesitate to give feedback and especially report bugs or
-ask for new features through launchpad at this URL: https://bugs.launchpad.net/anybox.recipe.openerp/+bugs
-
 
=== added file 'doc/contributing.rst'
--- doc/contributing.rst	1970-01-01 00:00:00 +0000
+++ doc/contributing.rst	2014-02-06 07:42:46 +0000
@@ -0,0 +1,187 @@
+For contributors
+================
+
+Source and tracking
+~~~~~~~~~~~~~~~~~~~
+The recipe is currently hosted as a launchpad project, under Bazaar
+version control: https://launchpad.net/anybox.recipe.openerp
+
+We follow the standard launchpad workflow (bugs, merge requests…).
+Code contributors are systematically added to the list of
+contributors at the end of the README, unless they explicitely wish
+not to (what Launchpad does is obvisouly out of our scope).
+
+There are currently no branch naming rules.
+
+Members of the "Anybox" team have push privileges on the main branches.
+
+Using a development version
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To use a local version of the recipe, you may use the ``develop``
+general buildout option::
+
+  [buildout]
+  develop = /path/to/anybox.recipe.openerp
+
+To track the latest version of a ``bzr`` branch of the recipe, we find
+the
+`gp.vcsdevelop <https://pypi.python.org/pypi/gp.vcsdevelop>`_
+extension simple and useful. Here's an example (excerpt from
+``buildot/recipe-trunk.cfg``)::
+
+  [buildout]
+  extensions = gp.vcsdevelop
+  vcs-extend-develop = bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/trunk#egg=anybox.recipe.openerp
+  vcs-update = True
+
+.. note::
+  Actually some parts of the recipe are aware of the possible use
+  of ``gp.vcsdevelop`` for python dependencies, and special care of it is
+  taken in the freeze and extract features. This is known to work even
+  for ``zc.buildout`` itself.
+
+Development setup
+~~~~~~~~~~~~~~~~~
+
+We recommend "developping" the source code in a virtualenv, together
+with ``bzr``. For instance::
+
+  virtualenv recipe-env
+  recipe-env/bin/pip install bzr
+  recipe-env/bin/bzr branch lp:anybox.recipe.openerp
+  cd anybox.recipe.openerp
+  python setup.py develop
+
+Coding style
+~~~~~~~~~~~~
+
+The recipe follows the same strong code development coding principles
+as many other projects:
+
+* Style enforcement : we follow the PEP8 guidelines
+* Static analysis with `flake8 <https://pypi.python.org/pypi/flake8>`_
+  (combines conveniently `pep8 <https://pypi.python.org/pypi/pep8>`_
+  and `pyflakes <https://pypi.python.org/pypi/pyflakes>`_).
+* Unit tests : we try and test as much as possible. It is hard to achieve a
+  real 100% with a tool that calls so many external processes, but
+  this is mitigated by our
+  :ref:`continuous integration <continuous_integration>` practice of
+  doing real OpenERP installations with the latest revision of the recipe.
+
+Launching static analysis and unit tests
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Install ``nose``, ``flake8`` and, optionally, ``coverage``::
+
+   recipe-env/bin/pip install nose coverage flake8==2.0 \
+                      pep8=1.4.6 mccabe==0.2.1 pyflakes==0.7.3 nose
+
+
+.. note:: we've had problems lately with discrepancies in ``pep8``
+          versions, that's why versions of ``flake8`` and its
+          dependencies are fixed above. In case of doubt, check what
+          the buildbot is actually running.
+
+Run ``flake8`` and the tests::
+
+    cd anybox.recipe.openerp
+    flake8 anybox && nosetests anybox --with-doctest
+
+There is also this convenience to run the tests and output a coverage report::
+
+    source ./test-cover
+
+
+.. _integration tests:
+
+Integration tests
+~~~~~~~~~~~~~~~~~
+
+There is a special category of tests: those that need a real OpenERP
+instance, built with the recipe, to run.
+
+They are located within the ``tests_with_openerp`` subdirectory and
+need to be launched with a launcher script constructed by the recipe.
+
+For example, create a testing buildout like this::
+
+  [openerp]
+  # version as you wish
+  eggs = nose
+  openerp_scripts nosetests command-line-options = -d
+
+Then run ``bin/buildout``, create a database and initialize it. From
+the buildout directory::
+
+  createdb test-recipe
+  bin/start_openerp -d test-recipe -i base --stop-after-init
+
+You can then run the tests::
+
+  bin/nosetests_openerp -d test-recipe -- /path/to/recipe/branch/tests_with_openerp
+
+Currently, these tests are all about the ``Session`` objects, used in
+scripts.
+
+.. note:: you may use a different version of the recipe to build that
+          testing buildout. This is anyway what happens if you build
+          with your development version, and hack some changes
+          afterwards.
+
+          Using a very different version of the recipe could give
+          funky results, but you're supposed to know what you're doing
+          at this point.
+
+
+.. _continuous_integration:
+
+Continuous integration
+~~~~~~~~~~~~~~~~~~~~~~
+
+Basic builds
+------------
+
+Upon each push on the main branches, Anybox' public
+buildbot awakes to check the coding style, run the tests and build
+this documentation. You may check the status there:
+
+* `trunk builder
+  <http://buildbot.anybox.fr/waterfall?show=anybox.recipe.openerp>`_
+* `stable builder
+  <http://buildbot.anybox.fr/waterfall?show=anybox.recipe.openerp-stable>`_
+
+Actual runs
+-----------
+
+Furthermore, this buildbot instance runs `anybox.buildbot.openerp
+<https://pypi.python.org/pypi/anybox.buildbot.openerp>`_,
+a buildbot configurator for OpenERP installations based on the recipe.
+
+This is used in turn to run high-level integration tests, having the
+latest bzr version of the recipe actually install several combinations
+of OpenObject server and addons, and run their unit tests.
+
+The configuration is stored in the ``buildbot`` subdirectory of the
+recipe trunk branch. It is made of a high level configuration file
+(``MANIFEST.cfg``) and buildout configuration files. This buildbot
+instance actually aggregates several such configurations.
+
+The corresponding builders are those whose name starts with
+``recipe-`` or ``stable-recipe-`` in the `builders list
+<http://buildbot.anybox.fr/builders>`_.
+
+.. note:: the `integration tests`_ mentioned above are executed in
+          particular during this process, currently in the
+          ``recipe-7.0-postgresql-9.2`` builder.
+
+Some builds may appear to be broken because of tests failures been
+pushed by upstream in OpenERP itself or in the tested addons, but it's
+easy to check whether this is due to a recipe failure or not.
+
+.. note::
+
+   Anybox hardware resources are limited; contributing buildslaves would
+   be greatly appreciated.
+
+
 
=== added file 'doc/dev_prod_workflow.rst'
--- doc/dev_prod_workflow.rst	1970-01-01 00:00:00 +0000
+++ doc/dev_prod_workflow.rst	2014-02-06 07:42:46 +0000
@@ -0,0 +1,32 @@
+Full development to production example
+=======================================
+
+In this example, we present one way of organizing a project, to
+provide easy to install development setups, continuous integration and
+production deployments.
+
+Please read this as a pattern among many others. If you decide to base
+your development process on it, you'll have to adapt it to your team's
+practice anyway.
+
+Common setup
+~~~~~~~~~~~~
+
+Developer's setup
+~~~~~~~~~~~~~~~~~
+Here we add private read-write access to version control systems.
+We need to version the buildout itself, and make decisions about which
+addons will be under active development within that project.
+
+At this point, asking a developer to work on the project is as simple
+as providing the main URL to get the buildout from VCS.
+
+Release and packaging
+~~~~~~~~~~~~~~~~~~~~~
+Use of ``freeze-to``, ``extract-downloads-to``, and production of a tarball.
+
+Deployment with a server-local configuration file
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+You may decide to track the local files with a VCS, too, but it's
+preferable to keep it distinct from the main code base.
+
 
=== added file 'doc/first_steps.rst'
--- doc/first_steps.rst	1970-01-01 00:00:00 +0000
+++ doc/first_steps.rst	2014-02-06 07:42:46 +0000
@@ -0,0 +1,351 @@
+First steps
+===========
+
+
+.. _howto:
+
+How to create and bootstrap a buildout
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To create a buildout and run the build, you just need **1 file** and **2 commands**:
+
+- Create a single ``buildout.cfg`` file.
+- Be sure you installed all your build dependencies
+- Bootstrap the buildout with: ``python bootstrap.py``
+- Run the build with: ``bin/buildout``
+
+The same with more details below :
+
+Creating the buildout
+---------------------
+
+Create a ``buildout.cfg`` file in an empty directory, containing the
+configuration of the `example 6.1`_ section.
+
+.. _dependencies:
+
+Installing build dependencies
+-----------------------------
+
+You basically need typical development tools needed to build all the Python
+dependency eggs of OpenERP. You can do this by yourself with your system or
+Linux distribution.
+
+Or if you're using a Debian based distribution, we provide a single
+dependency package you can use to install all dependencies in one shot:
+
+Add the following line in your ``/etc/apt/sources.list``::
+
+  deb http://apt.anybox.fr/openerp common main
+
+If you don't want your system to complain about non-signed packages,
+have it accept the signing key, e.g. by issuing::
+
+  sudo apt-key adv --keyserver hkp://subkeys.pgp.net --recv-keys 0xE38CEB07
+
+(sometimes, the key server is too busy, you may need to wait a few
+minutes and try again)
+
+Install the dependency package::
+
+  $ sudo aptitude update
+  $ sudo aptitude install openerp-server-system-build-deps
+
+You can uninstall this package with ``aptitude`` after the build to
+automatically remove all un-needed dependencies, but you need to
+install *run dependencies* before that ::
+
+  $ sudo aptitude install openerp-server-system-run-deps
+  $ sudo aptitude remove openerp-server-system-build-deps
+
+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.
+
+Bootstrapping the buildout
+--------------------------
+Bootstrapping the buildout consists in creating the basic structure of
+the buildout, and installing buildout itself in the directory.
+Once it's been done, everything is under tight control.
+
+The easiest way to bootstrap is to use the ``bootstrap.py`` script::
+
+  $ wget https://raw.github.com/buildout/buildout/master/bootstrap/bootstrap.py
+
+As of zc.buildout version 2.2, strong isolation from the system-wide Python
+installation has been abandoned because of its redundancy with the
+very popular `virtualenv <https://pypi.python.org/pypi/virtualenv>`_.
+Besides, the bootstrap actually fails if a version of
+setuptools older than 0.7 is present system-wide (happens easily
+enough at the time of this writing).
+
+The universal current way of doing is therefore to start from a
+virtualenv *without setuptools*. For virtualenv >= 1.9, just do::
+
+  $ virtualenv sandbox --no-setuptools
+
+For older versions of virtualenv::
+
+  $ virtualenv sandbox
+  $ sandbox/bin/pip uninstall setuptools pip
+
+.. note:: to install virtualenv.
+
+          * Debian family: sudo aptitude install python-virtualenv
+          * Redhat/Fedora/CenOS family: sudo yum install python-virtualenv
+
+Finally, perform the bootstrap with the virtualenv's Python::
+
+  $ sandbox/bin/python bootstrap.py
+
+From now on, all buildout related operations, including OpenERP
+startup script, custom scripts will be protected by this virtualenv.
+
+.. note:: nothing, not even ``zc.buildout`` actually gets installed by
+          buildout in such a virtualenv.
+          It's *totally safe* if you're managing several buildouts to
+          share a single such virtualenv among all of them.
+
+.. note:: since the bootstrap operation is so sensitive, we recommend
+          package managers to include the precise ``bootstrap.py`` in
+          their distributed buildout, and to bundle a future-proof
+          shell script, using options such as ``-v``.
+
+
+Running the build
+-----------------
+
+Just run ::
+
+  $ bin/buildout
+
+Starting OpenERP
+----------------
+
+Just run ::
+
+  $ bin/start_openerp
+
+.. _example 7.0:
+
+Example OpenERP 7.0 buildouts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This example builds the latest nightly OpenERP 7 version.
+Note how most Python distribution versions are pinned.
+
+While not mandatory, version pinning is an
+important part of the buildout culture. Note also how even ``zc.buildout``
+and the current recipe versions can be pinned::
+
+  [buildout]
+  parts = openerp
+  versions = versions
+  find-links = http://download.gna.org/pychart/
+
+  [openerp]
+  recipe = anybox.recipe.openerp[bzr]:server
+  version = nightly 7.0 latest
+
+  [versions]
+  setuptools = 1.1.0
+  zc.buildout = 2.2.1
+  zc.recipe.eggs = 2.0.0
+  anybox.recipe.openerp = 1.7.1
+  babel = 0.9.6
+  Pillow = 1.7.1
+  pywebdav = 0.9.4.1
+  PyXML = 0.8.4
+  pyyaml = 3.10
+  werkzeug = 0.8.3
+  zsi = 2.0-rc3
+  feedparser = 5.1.1
+  gdata = 2.0.16
+  lxml = 2.3.3
+  psycopg2 = 2.4.4
+  pydot = 1.0.28
+  pyparsing = 1.5.6
+  python-dateutil = 1.5
+  python-ldap = 2.4.9
+  python-openid = 2.2.5
+  pytz = 2012b
+  vatnumber = 1.0
+  vobject = 0.8.1c
+  xlwt = 0.7.3
+
+Of course, installing the latest nightly release provided by OpenERP
+is not really interesting. The flexibility is.
+
+Here's an example with the latest versions of the 7.0 Bazaar branches
+on Launchpad as lightweight checkouts (to avoid hour long downloads).
+We don't repeat the ``buildout`` and ``versions`` sections::
+
+  [openerp]
+  recipe = anybox.recipe.openerp[bzr]:server
+  version = bzr lp:openobject-server/7.0 openerp-7.0 last:1 bzr-init=lightweight-checkout
+  addons = bzr lp:openobject-addons/7.0 addons-7.0 last:1 bzr-init=lightweight-checkout
+           bzr lp:openerp-web/7.0 addons-web-7.0 last:1 subdir=addons bzr-init=lightweight-checkout
+
+Now imagine how easily one can switch branches and redistribute a
+ready-to-run buildout on some dedicated support branch, Git mirrors, etc.
+
+The next example is on 6.1 and demonstrates both how to add specific addons
+directories, and how uniform it is.
+
+.. _example 6.1:
+
+Example OpenERP 6.1 buildout with a custom addon
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Here is a very simple example for a latest OpenERP 6.1 nightly and a
+custom addon hosted on Bitbucket::
+
+    [buildout]
+    parts = openerp 
+    versions = versions
+    find-links = http://download.gna.org/pychart/
+    
+    [openerp]
+    recipe = anybox.recipe.openerp:server
+    version = nightly 6.1 latest
+    addons = hg https://bitbucket.org/anybox/anytracker addons-at default
+
+    [versions]
+    MarkupSafe = 0.15
+    Pillow = 1.7.7
+    PyXML = 0.8.4
+    babel = 0.9.6
+    feedparser = 5.1.1
+    gdata = 2.0.16
+    lxml = 2.3.3
+    mako = 0.6.2
+    psycopg2 = 2.4.4
+    pychart = 1.39
+    pydot = 1.0.28
+    pyparsing = 1.5.6
+    python-dateutil = 1.5
+    python-ldap = 2.4.9
+    python-openid = 2.2.5
+    pytz = 2012b
+    pywebdav = 0.9.4.1
+    pyyaml = 3.10
+    reportlab = 2.5
+    simplejson = 2.4.0
+    vatnumber = 1.0
+    vobject = 0.8.1c
+    werkzeug = 0.8.3
+    xlwt = 0.7.3
+    zc.buildout = 1.5.2
+    zc.recipe.egg = 1.3.2
+    zsi = 2.0-rc3
+
+
+.. note:: 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.
+
+
+Example OpenERP 6.0 buildout (server and clients)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Here is a sample buildout with version specification, 2 OpenERP servers (with
+one using the latest 6.0 branch on the launchpad) using only NETRPC and
+listening on 2 different ports, and 2 web clients::
+
+    [buildout]
+    parts = openerp1 web1 openerp2 web2
+    #allow-picked-versions = false
+    versions = versions
+    find-links = http://download.gna.org/pychart/
+    
+    [openerp1]
+    recipe = anybox.recipe.openerp:server
+    version = 6.0.3
+    options.xmlrpc = False
+    options.xmlrpcs = False
+    
+    [web1]
+    recipe = anybox.recipe.openerp:webclient
+    version = 6.0.3
+    
+    [openerp2]
+    recipe = anybox.recipe.openerp[bzr]:server
+    version = bzr lp:openobject-server/6.0 openobject-server-6.x last:1
+
+    options.xmlrpc = False
+    options.xmlrpcs = False
+    options.netrpc_port = 8170
+    
+    [web2]
+    recipe = anybox.recipe.openerp:webclient
+    version = 6.0.3
+    global.openerp.server.port = '8170'
+    global.server.socket_port = 8180
+    
+    [versions]
+    MarkupSafe = 0.15
+    Pillow = 1.7.7
+    anybox.recipe.openerp = 0.9
+    caldav = 0.1.10
+    collective.recipe.cmd = 0.5
+    coverage = 3.5
+    distribute = 0.6.25
+    feedparser = 5.0.1
+    lxml = 2.1.5
+    mako = 0.4.2
+    nose = 1.1.2
+    psycopg2 = 2.4.2
+    pychart = 1.39
+    pydot = 1.0.25
+    pyparsing = 1.5.6
+    python-dateutil = 1.5
+    pytz = 2012b
+    pywebdav = 0.9.4.1
+    pyyaml = 3.10
+    reportlab = 2.5
+    vobject = 0.8.1c
+    z3c.recipe.scripts = 1.0.1
+    zc.buildout = 1.5.2
+    zc.recipe.egg = 1.3.2
+    Babel = 0.9.6
+    FormEncode = 1.2.4
+    simplejson = 2.1.6
+
+Continuously tested examples
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+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
+<http://pypi.python.org/pypi/anybox.recipe.openerp>`_), and are
+continuously tested in the
+`anybox buildbot <http://buildbot.anybox.fr/>`_ which is powered by
+`anybox.buildbot.openerp
+<http://pypi.python.org/pypi/anybox.buildbot.openerp>`_.
+
+See also :ref:`continuous_integration` for more details about these
+tested examples.
+
+Other sample buildouts
+~~~~~~~~~~~~~~~~~~~~~~
+
+Here are a few ready-to-use buildouts:
+
+(Be sure to install system dependencies_ first)
+
+OpenERP with the development branches of the Magento connector addons::
+
+  $ hg clone https://bitbucket.org/anybox/openerp_connect_magento_buildout
+  $ cd openerp_connect_magento_buildout
+  $ python bootstrap.py
+  $ bin/buildout
+  $ bin/start_openerp
+
+OpenERP with the development branches of the Prestashop connector addons::
+
+  $ hg clone https://bitbucket.org/anybox/openerp_connect_prestashop_buildout
+  $ cd openerp_connect_prestashop_buildout
+  $ python bootstrap.py
+  $ bin/buildout
+  $ bin/start_openerp
+
 
=== added file 'doc/index.rst'
--- doc/index.rst	1970-01-01 00:00:00 +0000
+++ doc/index.rst	2014-02-06 07:42:46 +0000
@@ -0,0 +1,79 @@
+.. OpenERP buildout recipe documentation master file, created by
+   sphinx-quickstart on Wed Jul 24 18:32:19 2013.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+OpenERP buildout recipe
+=======================
+
+This recipe for `Buildout <https://github.com/buildout/buildout>`_ is
+a fully featured tool allowing you to define and deploy quickly
+OpenERP installations of any kinds, ranging from development setups to
+fully automated production deployments or continuous integration.
+
+Some of its main features include:
+
+* uniformity across OpenERP versions (from 5.0 onwards)
+* installation of OpenERP server and, if meaningful, GTK and web clients.
+* retrieval of main software and addons from various sources,
+  including the major version control systems
+* ability to pinpoint everything for replayability
+* management of OpenERP configuration
+* dedicated scripts creation for easy integration of external tools,
+  such as test launchers
+* packaging: creation of self-contained equivalents for easy
+  deployment in tightly controlled hosting environmenents.
+
+All these to be considered together with zc.buildout‘s general
+properties, such as an extensible configuration file format for easy
+variation or separation of concerns, native Python distributions
+installation, and of course the huge ecosystem of other recipes.
+
+About this documentation
+------------------------
+
+The full documentation is written with `Sphinx
+<http://sphinx-doc.org>`_, built continuously and
+uploaded to http://docs.anybox.fr/anybox.recipe.openerp/trunk by Anybox' public
+buildbot.
+The Sphinx source tree is to be found under the ``doc`` subdirectory
+of this project.
+
+Although this Sphinx documentation started with version 1.8.0, most of
+its contents applies to the 1.7 series: features introduced with 1.8
+are highlighted, and readers may consult the `changelog on PyPI
+<https://pypi.python.org/pypi/anybox.recipe.openerp#changes>`_.
+
+We plan to upload released versions of the documentation to
+http://pythonhosted.org
+
+Contents
+--------
+
+.. toctree::
+   :maxdepth: 2
+   :glob:
+
+   first_steps
+   configuration
+   scripts
+   dev_prod_workflow
+   contributing
+
+Code documentation
+------------------
+
+.. toctree::
+   :maxdepth: 1
+   :glob:
+
+   apidoc/anybox*
+
+
+Indices and tables
+------------------
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`
+
 
=== added file 'doc/scripts.rst'
--- doc/scripts.rst	1970-01-01 00:00:00 +0000
+++ doc/scripts.rst	2014-02-06 07:42:46 +0000
@@ -0,0 +1,471 @@
+OpenERP Scripts
+===============
+
+The server recipe actually includes a general engine to install Python
+code that needs access to the OpenERP API and build
+configuration-aware executables.
+
+As usual, it tries and do so by bridging the standard Python packaging
+practice (setuptools-style console scripts, as in
+``zc.recipe.egg:scripts``) and OpenERP specificities.
+
+We call such scripts *OpenERP scripts* to distinguish them among the
+more general concept of console scripts.
+
+.. warning:: OpenERP scripts are currently supported for OpenERP ≥ 6.1 only.
+
+
+Use cases
+~~~~~~~~~
+
+OpenERP scripts can do great in situations where an RPC script might
+not be powerful enough or not practical. Some examples:
+
+* specific batch jobs, especially for large databases (you get to
+  control the transaction).
+* introspection tools.
+* general-purposes test launchers that don't have any knowledge of
+  OpenERP specifics, such as ``nose``. See :ref:`command_line_options`
+  for details about that.
+
+OpenERP vs RPC scripts for administrative tasks
+-----------------------------------------------
+
+There are several Python distributions that wrap the OpenERP RPC APIs
+for easy use within Python code.
+
+Using an RPC script for administrative tasks usually leads to
+wrap it in a shell script, with the admin password in clear text.
+
+In this author's experience of applicative maintainance,
+this always turns to be an
+easy source of breakage that may look to be trivial at first sight but
+has actually two nasty properties : it may stay unnoticed for a while,
+and it lies at the interface between responsibilities.
+
+In case of password change, the persons who can do it
+in the database and in the system usually differ, and may not
+communicate on a regular basis. In enterprise hosting environments,
+you may have to explain stuff to several project managers with
+different responsabilities, go through crisis management meetings,
+etc. Who wants to waste hours of their life interacting with people
+under stress to try and persuade them that it's only a matter of
+changing an obscure password ?
+
+
+OpenERP scripts vs Openerp cron jobs
+------------------------------------
+
+Because they are part of addons, OpenERP cron jobs also have full
+unrestricted access to the internal API, and obviously don't suffer
+from the password plague.
+
+Some ideas to make a choice:
+
+* who should control, schedule and tune execution (a system administrator or
+  a functional admin)
+* which one the script author finds easiest to write for
+* reuse and distribution issues : OpenERP scripts are in Python
+  distributions, cron jobs are in addons.
+* OpenERP scripts must implement their own transaction control,
+  whereas cron jobs don't bother about it but rely on the framework's
+  decisions.
+
+Perhaps, the best is not to choose : put the bulk of the logic in some
+technical addon, it's easy to rewrap it in an OpenERP script and as a
+cron job.
+
+
+Declaring OpenERP Scripts
+~~~~~~~~~~~~~~~~~~~~~~~~~
+There are several cases, depending on the script authors
+intentions. Script authors should therefore state clearly in their
+documentation how to declare them.
+
+Assume to fix ideas there is a Python distribution ``my.script``
+that declares a console script entry point named ``my_script`` in its
+``setup.py``::
+
+      entry_points="""
+
+      [console_scripts]
+      my_script = my.script.main:run
+      """
+
+The first thing to do is to require that distribution using the
+``eggs`` option::
+
+  [my-openerp]
+  (...)
+  eggs = my.script
+
+:ref:`How that distribution can be made available to buildout
+<making_available>` is a different question.
+
+Bare declararations
+-------------------
+The following configuration::
+
+  [openerp-one]
+  (...)
+  openerp_scripts = my_script
+
+Produces an executable ``bin/my_script-openerp-one``, that can import
+OpenERP server and addons code, and in which the OpenERP configuration
+related to the appropriate buildout part (here, ``openerp-one``) is
+loaded in the standard ``openerp.tools.config``, for use in the
+script. The script has to take care of all database management operations.
+
+Optionally, it's possible to specify the name of the produced script::
+
+  [openerp-one]
+  (...)
+  openerp_scripts = my_script=wished_name
+
+That would build the script as ``bin/wished_name``.
+
+This is good
+enough for scripts that'd take care of many bootstrapping details, but
+there is a more integrated way that script authors should be aware of:
+the special ``session`` argument.
+
+.. _arguments_session:
+
+Arguments and session
+---------------------
+.. note:: new in version 1.7.0
+
+An ``arguments`` parameter, similar to the one of