anybox.recipe.openerp Package

anybox.recipe.openerp Package

base Module

class anybox.recipe.openerp.base.BaseRecipe(buildout, name, options)

Bases: object

Base class for other recipes.

It implements notably fetching of the main software part plus addons.

The 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 main_software singleton (see 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, 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 anybox.recipe.openerp.vcs) can implemented their dedicated options

The merges attribute is a dict storing how to fetch additional changes to merge into VCS type sources:

local path -> [(type, location_spec, options), ... ]

See sources for the meaning of the various components. Note that in merges, values are a list of triples instead of only a single triple as values in sources because there can be multiple merges on the same local path.

addons_paths = ()

apply_version_dependent_decisions()

Store some booleans depending on detected version.

To be refined by subclasses.

buildout_cfg_name(argv=None)

Return the name of the config file that’s been called.

cleanup_openerp_dir()

Revert local modifications that have been made during installation.

These can be, e.g., forbidden by the freeze process.

develop(src_directory, setup_has_pil=False)

Develop the specified source distribution.

Any call to zc.recipe.eggs will use that developped version. develop() launches a subprocess, to which we need to forward the paths to requirements via PYTHONPATH.

Parameters:setup_has_pil – if True, an altered version of setup that does not require PIL is produced to perform the develop, so that installation can be done with Pillow instead. Recent enough versions of OpenERP/Odoo are directly based on Pillow. Returns:project name of the distribution that’s been “developed” This is useful for OpenERP/Odoo itself, whose project name changed within the 8.0 stable branch.

dump_nightly_latest_version()

After download/analysis of ‘nightly latest’, give equivalent spec.

extract_downloads_to(target_dir, outconf_name='release.cfg')

Extract anything that has been downloaded to target_dir.

This doesn’t copy intermediary buildout configurations nor local parts. In the purpose of making a self-contained and offline playable archive, these are assumed to be already taken care of.

finalize_addons_paths(check_existence=True)

Add implicit paths and serialize in the addons_path option.

if check_existence is True, all the paths will be checked for existence.

freeze_to(out_config_path)

Create an extension buildout freezing current revisions & versions.

insert_odoo_git_addons(base_addons)

Insert the standard, non-base addons bundled within Odoo git repo.

See lp:1327756

These addons are also part of the Github branch for prior versions, therefore we cannot rely on version knowledge; we check for existence instead. If not found (e.g, we are on a nightly for OpenERP <= 7), this method does nothing.

The ordering of the different paths of addons is important. When several addons at different paths have the same name, the first of them being found is used. This can be used, for instance, to replace an official addon by another one by placing a different addons’ path before the official one.

If the official addons’ path is already set in the config file (e.g. at the end), it will leave it at the end of the paths list, if it is not set, it will be placed at the beginning just after base addons’ path.

Care is taken not to break configurations that corrected this manually with a local source in the addons option.

Parameters:base_addons – the path to previously detected base addons, to properly insert right after them

install()

install_recipe_requirements()

Install requirements for the recipe to run.

install_requirements()

Install egg requirements and scripts.

If some distributions are known as soft requirements, will retry without them

is_git_layout = False

True if this is the git layout, as seen from the move to GitHub.

In this layout, the standard addons other than base are in a addons directory right next to the openerp package.

is_stale_http_head()

Tell if the download is stale by doing a HEAD request.

Assumes the correct date had been written upon download. This is the same system as in GNU Wget 1.12. It works even if the server does not implement conditional responses such as 304

main_download()

HTTP download for main part of the software to self.archive_path.

main_http_caching = 'filename'

major_version

make_absolute(path)

Make a path absolute if needed.

If not already absolute, it is interpreted as relative to the buildout directory.

merge_requirements()

Merge eggs option with self.requirements.

nightly_dl_url = {'8.0': 'http://nightly.odoo.com/8.0/nightly/src/', '7.0': 'http://nightly.odoo.com/7.0/nightly/src/', 'trunk': 'http://nightly.odoo.com/trunk/nightly/src/', '6.1': 'http://nightly.odoo.com/6.1/nightly/src/', '6.0': 'http://nightly.odoo.com/6.0/6.0/'}

parse_addons(options)

Parse the addons options into sources.

See BaseRecipe for the structure of sources.

parse_merges(options)

Parse the merge options into merges.

See BaseRecipe for the structure of merges.

parse_revisions(options)

Parse revisions options and update sources.

It is assumed that sources has already been populated, and notably has a main_software entry. This allows for easy fixing of revisions in an extension buildout

See BaseRecipe for the structure of sources.

parse_version()

Set the main software in sources and related attributes.

preinstall_version_check()

Perform version checks before any attempt to install.

To be subclassed.

read_openerp_setup()

Ugly method to extract requirements & version from ugly setup.py.

Primarily designed for 6.0, but works with 6.1 as well.

read_release()

Try and read the release.py file directly.

Should be used only if reading setup.py failed, which happens with OpenERP 5.0

recipe_requirements = ()

recipe_requirements_paths = ()

release_dl_url = {'5.0': 'http://nightly.odoo.com/old/openerp-5/', '6.1': 'http://nightly.odoo.com/old/openerp-6.1/', '6.0': 'http://nightly.odoo.com/old/openerp-6/'}

requirements = ()

retrieve_addons()

Peform all lookup and downloads specified in sources.

See BaseRecipe for the structure of sources.

retrieve_main_software()

Lookup or fetch the main software.

See MainSoftware and BaseRecipe for explanations.

retrieve_merges()

Peform all VCS merges specified in merges.

revert_sources()

Revert all sources to the revisions specified in sources.

sandboxed_tar_extract(sandbox, tarfile, first=None)

Extract those members that are below the tarfile path ‘sandbox’.

The tarfile module official doc warns against attacks with .. in tar.

The option to start with a first member is useful for this case, since the recipe consumes a first member in the tar file to get the openerp main directory in parts. It is taken for granted that this first member has already been checked.

soft_requirements = ()

update()

class anybox.recipe.openerp.base.MainSoftware

Bases: object

Placeholder to represent the main software instead of an addon location.

Should just have a singleton instance: main_software, whose meaning depends on the concrete recipe class using it.

For example, in anybox.recipe.openerp.server.ServerRecipe, main_software represents the OpenObject server or the OpenERP standard distribution.

anybox.recipe.openerp.base.rfc822_time(h)

Parse RFC 2822-formatted http header and return a time int.

devtools Module

Provide devtools to openerp.

anybox.recipe.openerp.devtools.load(for_tests=False)

gtkclient Module

class anybox.recipe.openerp.gtkclient.GtkClientRecipe(buildout, name, options)

Bases: anybox.recipe.openerp.base.BaseRecipe

Recipe for gtk client and config

recipe_requirements = ()

release_filenames = {'5.0': 'openerp-client-%s.tar.gz', '6.1': 'openerp-client-%s.tar.gz', '6.0': 'openerp-client-%s.tar.gz'}

requirements = ('pydot',)

server Module

class anybox.recipe.openerp.server.ServerRecipe(*a, **kw)

Bases: anybox.recipe.openerp.base.BaseRecipe

Recipe for server install and config

apply_version_dependent_decisions()

Store some booleans depending on detected version.

Also does some options normalization accordingly.

archeo_requirements = {(5, 0): ['psycopg2', 'pytz', 'lxml', 'egenix-mx-base', 'reportlab', 'pydot']}

merge_requirements()

Prepare for installation by zc.recipe.egg

• add Pillow iff PIL not present in eggs option.
• (OpenERP >= 6.1) develop the openerp distribution and require it
• gunicorn’s related dependencies if needed

For PIL, extracted requirements are not taken into account. This way, if at some point, OpenERP introduce a hard dependency on PIL, we’ll still install Pillow. The only case where PIL will have precedence over Pillow will thus be the case of a legacy buildout. See https://bugs.launchpad.net/anybox.recipe.openerp/+bug/1017252

Once ‘openerp’ is required, zc.recipe.egg will take it into account and put it in needed scripts, interpreters etc.

nightly_filenames = {'8.0': 'odoo_8.0-%s.tar.gz', '7.0': 'openerp-7.0-%s.tar.gz', '6.1': 'openerp-6.1-%s.tar.gz', 'trunk': 'odoo_9.0alpha1-%s.tar.gz'}

recipe_requirements = ('babel',)

release_filenames = {'5.0': 'openerp-server-%s.tar.gz', '6.1': 'openerp-%s.tar.gz', '6.0': 'openerp-server-%s.tar.gz'}

requirements = ('pychart', 'anybox.recipe.openerp')

server_wide_modules = ()

soft_requirements = ('openerp-command',)

template_upgrade_script = '/home/gracinet/odoo/recipe/a.r.odoo/anybox/recipe/openerp/upgrade.py.tmpl'

with_gunicorn = False

with_openerp_command = False

with_upgrade = True

ws = None

testing Module

Utilities for unit tests.

class anybox.recipe.openerp.testing.FakeRepo(target_dir, url, clear_retry=False, offline=False, clear_locks=False, **options)

Bases: anybox.recipe.openerp.vcs.base.BaseRepo

archive(target)

get_update(revision)

log = []

log_std_options = True

name = 'fakevcs'

parents(pip_compatible=False)

revert(revision)

revision = 'fakerev'

vcs_control_dir = '.fake'

class anybox.recipe.openerp.testing.PersistentRevFakeRepo(target_dir, url, clear_retry=False, offline=False, clear_locks=False, **options)

Bases: anybox.recipe.openerp.testing.FakeRepo

A variant of FakeRepo that still needs the directory structure around.

Makes for a more realistic test of some conditions. In particular, reproduced launchpad #TODO

current_revisions = {}

revision

uncommitted_changes()

This needs the directory to really exist and is controllable.

class anybox.recipe.openerp.testing.RecipeTestCase(methodName='runTest')

Bases: unittest.case.TestCase

A base setup for tests of recipe classes

build_babel_egg()

build an egg for fake babel in buildout’s eggs directory.

Require the test case to already have a test_dir attribute (typically set on class with the dirname of the test)

fill_working_set()

make_recipe(name='openerp', **options)

setUp()

tearDown()

class anybox.recipe.openerp.testing.TestingRecipe(buildout, name, options)

Bases: anybox.recipe.openerp.base.BaseRecipe

A subclass with just enough few defaults for unit testing.

nightly_filenames = {'6.1': '6-1-nightly-%s.tbz'}

release_filenames = {'6.1': 'blob-%s.tgz', '6.0': 'bl0b-%s.tgz'}

anybox.recipe.openerp.testing.clear_vcs_log()

anybox.recipe.openerp.testing.get_vcs_log()

utils Module

class anybox.recipe.openerp.utils.WorkingDirectoryKeeper

Bases: object

A context manager to get back the working directory as it was before.

If you want to stack working directory keepers, you need a new instance for each stage.

active = False

anybox.recipe.openerp.utils.check_output(*popenargs, **kwargs)

Backport of subprocess.check_output from python 2.7.

Example (this doctest would be more readable with ELLIPSIS, but that’s good enough for today):

>>> out = check_output(["ls", "-l", "/dev/null"])
>>> out.startswith('crw-rw-rw')
True

The stdout argument is not allowed as it is used internally. To capture standard error in the result, use stderr=STDOUT.

>>> os.environ['LANG'] = 'C'  # for uniformity of error msg
>>> err = check_output(["/bin/sh", "-c",
...               "ls -l non_existent_file ; exit 0"],
...              stderr=subprocess.STDOUT)
>>> err.strip().endswith("No such file or directory")
True

anybox.recipe.openerp.utils.clean_object_files(directory)

Recursively remove object files in given directory.

Also remove resulting empty directories.

anybox.recipe.openerp.utils.is_object_file(filename)

True if given filename is a python object file.

anybox.recipe.openerp.utils.major_version(version_string)

The least common denominator of OpenERP versions : two numbers.

OpenERP version numbers are a bit hard to compare if we consider nightly 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 ‘saas~’ argument before the minor version number is stripped. For instance:

>>> major_version('7.saas~3')
(7, 3)

anybox.recipe.openerp.utils.option_splitlines(opt_val)

Split a multiline option value.

This function performs stripping of whitespaces and allows comments as ConfigParser would do. Namely:

• a line starting with a hash is a comment. This is already taken care of by zc.buildout parsing of the configuration file.

  ConfigParser does not apply this rule to the case where the hash is after some leading whitespace (e.g, line-continuation indentation) as in this example:

  [foo]
  bar = line1
    line2
  # this is a comment
    # this is not a comment, and will appear in 'bar' value
  

  Therefore this function does not have to perform anything with respect to hash-comments.

• everything after a semicolon following a whitespace is a comment:

  [foo]
  bar = line1
        line2 ;this is a comment
  

Parameters:opt_val (basestring) – the raw option value Returns:tuple of strings

doctests (less readable than examples above, but more authoritative):

>>> option_splitlines('line1\n  line2 ;this is a comment\n  line3')
('line1', 'line2', 'line3')
>>> option_splitlines('l1\n; inline comment from beginning\n  line3')
('l1', 'line3')
>>> option_splitlines('l1\n; inline comment from beginning\n  line3')
('l1', 'line3')
>>> option_splitlines('l1\n  ; disappears after stripping \n  line3')
('l1', 'line3')
>>> option_splitlines('line1\n\n')
('line1',)
>>> option_splitlines('')
()

For convenience, None is accepted:

>>> option_splitlines(None)
()

anybox.recipe.openerp.utils.option_strip(opt_val)

Same as option_splitlines() for a single line.

>>> option_strip("   hey, we have ; a comment")
'hey, we have'
>>> option_strip(None) is None
True

anybox.recipe.openerp.utils.total_seconds(td)

Uniformity backport of datetime.timedelta.total_seconds`()

Parameters:td – a datetime.timedelta instance Returns:the number of seconds in tdelta

The implementation for Python < 2.7 is taken from the standard library documentation

anybox.recipe.openerp.utils.use_or_open(*args, **kwds)

A context manager to use an open file if not None or open one.

Useful for code that should be unit-testable, but work on a default file if None is passed.

webclient Module

class anybox.recipe.openerp.webclient.WebClientRecipe(buildout, name, options)

Bases: anybox.recipe.openerp.base.BaseRecipe

Recipe for web client install and config

preinstall_version_check()

release_filenames = {'6.0': 'openerp-web-%s.tar.gz'}

requirements = ('setuptools',)

Subpackages

• runtime Subpackage
  • runtime Package
    • Runtime
  • session Module
  • upgrade Module
  • patch_openerp_v5 Module
  • start_openerp Module
  • test_openerp Module
• vcs Subpackage
  • vcs Package
  • base Module
  • bzr Module
  • git Module
  • hg Module
  • svn Module
  • testing Module