oca.recipe.odoo Package

oca.recipe.odoo Package

base Module

class oca.recipe.odoo.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 oca.recipe.odoo.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_odoo_requirements_file()

Try and read Odoo’s ‘requirements.txt’ and apply it.

This file appeared in the course of Odoo 8 lifetime. If not available, a warning is issued, that’s all.

Entries from the requirements file are applied if there is not already an entry in the versions section for the same project.

A more interesting behaviour would be to apply then if they don’t contradict an existing entry in the versions section, but that’s far more complicated.

apply_version_dependent_decisions()

Store some booleans depending on detected version.

To be refined by subclasses.

bool_opt_get(name, is_global=False)

Retrieve an option and interpret it as boolean.

Factorized to improve code readability.

Parameters:

is_global – if True, the option is taken from the global buildout options instead of the part taken care of by this recipe instance.

buildout_cfg_name(argv=None)

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

cleanup_odoo_dir()

Revert local modifications that have been made during installation.

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

develop(src_directory)

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.

Parameters:

check_existence – if True, all the paths will be checked for existence (useful for unit tests)

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 odoo 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

list_develops()

At any point in time, list the projects that have been developed.

This can work as soon as the recipe is instantiated (because the ‘buildout’ part) has already been executed. In particular, it does not rely on the workingset init done by zc.buildout.easy_install.Installer and can be used in precedence rules that need to be executed before calling the Installer indirectly via zc.recipe.eggs

Returns:

list of project names

Implementation simply lists the develop eggs directory There’s probably better to be done.

main_download()

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

main_http_caching = 'filename'

property 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(reqs=None)

Merge eggs option with self.requirements.

nightly_dl_url = {'10.0rc1c': 'http://nightly.odoo.com/10.0/nightly/src/'}

Base URLs to look for nightly versions.

The URL for 8.0 may have to be adapted once it’s released for good. This one is guessed from 7.0 and is needed by unit tests.

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_odoo_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.

Used as a fallback in case reading setup.py failed, which happened in an old OpenERP version. Could become the norm, but setup is also used to list dependencies.

recipe_requirements = ()

recipe_requirements_paths = ()

release_dl_url = {}

Base URLs to look for official, released versions.

There are currently no official releases for Odoo, but the recipe has been designed at the time of OpenERP 6.0 and some parts of its code at least expect this dict to exist. Besides, official releases may reappear at some point.

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 odoo main directory in parts. It is taken for granted that this first member has already been checked.

soft_requirements = ()

update()

with_odoo_requirements_file = False

Whether attempt to use the ‘requirements.txt’ shipping with Odoo

class oca.recipe.odoo.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 oca.recipe.odoo.server.ServerRecipe, main_software represents the OpenObject server or the Odoo standard distribution.

oca.recipe.odoo.base.get_content_type(msg)

Return the mimetype of the HTTP message. This is a helper to support Python 2 and 3.

oca.recipe.odoo.base.rfc822_time(h)

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

devtools Module

Provide devtools to openerp.

oca.recipe.odoo.devtools.load(for_tests=False)

server Module

class oca.recipe.odoo.server.ServerRecipe(*a, **kw)

Bases: BaseRecipe

Recipe for server install and config

apply_version_dependent_decisions()

Store some booleans depending on detected version.

Also does some options normalization accordingly. Currently, there is only one Odoo version, this method will be really useful again in a while.

merge_requirements(reqs=None)

Prepare for installation by zc.recipe.egg

• develop the odoo distribution and require it

• gunicorn’s related dependencies if needed

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

Historically, in anybox.recipe.openerp this used to take care of adding Pillow, which is now in Odoo’s setup.py.

nightly_filenames = {'10.0': 'odoo_10.0.%s.tar.gz', 'trunk': 'odoo_10.0alpha1.%s.tar.gz'}

Name of expected nightly tarballs in base URL, by major version.

recipe_requirements = ('babel',)

release_filenames = {}

requirements = ('oca.recipe.odoo',)

server_wide_modules = ()

soft_requirements = ('odoo-command',)

template_upgrade_script = '/opt/hostedtoolcache/Python/3.8.13/x64/lib/python3.8/site-packages/oca/recipe/odoo/upgrade.py.tmpl'

with_gunicorn = False

with_upgrade = True

ws = None

testing Module

Utilities for unit tests.

class oca.recipe.odoo.testing.FakeRepo(target_dir='.fake', url='.fake', **options)

Bases: BaseRepo

archive(target)

get_update(revision)

Make it so that the target directory is at the prescribed revision.

The target directory need not to be initialized: this method will “clone” it from the remote source (whatever that means in the considered VCS).

This method can fail under various circumstances, for instance if the wanted revision does not exist locally and offline mode has been selected.

Raises:

• CloneError – if initial cloning fails

• UpdateError – if update of existing repository fails

Must be implemented in concrete subclasses

is_local_fixed_revision(revspec)

True if revspec is a locally available fixed revision.

The concept of a fixed revision depends on the concrete VCS in use. It means that retrieving revspec at any point in the future

1. is guaranteed to work

2. always yields the same result

In practice, for most VCSes, these cannot be totally guaranteed, but each VCS defines those cases whose breaking is considered to be a very bad practice.

In Mercurial, removing a commit from a public repository is possible, but very bad. In Git, removing a commit from a public repository is normal workflow, but removing a tag is very bad.

The name stresses that only locally available ones will be recognized due to the promise that this method does not query any remote repo.

log = []

log_std_options = True

name = 'fakevcs'

parents(pip_compatible=False)

Return universal identifier for parent nodes, aka current revisions.

There might be more than one with some VCSes (ex: pending merge in hg).

Parameters:

pip_compatible – if True, only pip compatible revision specifications are returned, depending on the VCS type.

revert(revision)

Revert any local changes, including pending merges.

revision = 'fakerev'

schemes = ['fakevcs+http']

vcs_control_dir = '.fake'

class oca.recipe.odoo.testing.PersistentRevFakeRepo(target_dir='.fake', url='.fake', **options)

Bases: 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 = {}

property revision

str(object=’’) -> str str(bytes_or_buffer[, encoding[, errors]]) -> str

Create a new string object from the given object. If encoding or errors is specified, then the object must expose a data buffer that will be decoded using the given encoding and error handler. Otherwise, returns the result of object.__str__() (if defined) or repr(object). encoding defaults to sys.getdefaultencoding(). errors defaults to ‘strict’.

uncommitted_changes()

This needs the directory to really exist and is controllable.

class oca.recipe.odoo.testing.RecipeTestCase(methodName='runTest')

Bases: 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)

build_fictive_egg()

build an egg of a fictive distribution for testing purposes.

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

develop_fictive(require_install=False)

Develop fictive distribution in buildout’s directory.

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

Parameters:

require_install (bool) – if True, will be required from eggs option, and installed.

fictive_dist_name = 'FictiveDist'

fictive_name = 'fictivedist'

fictive_version = None

fill_working_set(fictive=False, babel=False)

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

setUp()

Hook method for setting up the test fixture before exercising it.

silence_buildout_develop()

Silence easy_install develop operations performed by zc.buildout.

tearDown()

Hook method for deconstructing the test fixture after testing it.

class oca.recipe.odoo.testing.TestingRecipe(buildout, name, options)

Bases: BaseRecipe

A subclass with just enough few defaults for unit testing.

nightly_filenames = {'10.0rc1c': '10-0-nightly-%s.tbz'}

release_dl_url = {'10.0': 'http://release.odoo.test/src/'}

Base URLs to look for official, released versions.

There are currently no official releases for Odoo, but the recipe has been designed at the time of OpenERP 6.0 and some parts of its code at least expect this dict to exist. Besides, official releases may reappear at some point.

release_filenames = {'10.0': 'blob-%s.tgz'}

oca.recipe.odoo.testing.clear_vcs_log()

oca.recipe.odoo.testing.get_vcs_log()

utils Module

class oca.recipe.odoo.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

oca.recipe.odoo.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['LC_ALL'] = '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

oca.recipe.odoo.utils.clean_object_files(directory)

Recursively remove object files in given directory.

Also remove resulting empty directories.

oca.recipe.odoo.utils.conf_ensure_section(conf, section)

oca.recipe.odoo.utils.is_object_file(filename)

True if given filename is a python object file.

oca.recipe.odoo.utils.major_version(version_string)

The least common denominator of Odoo versions : two numbers.

Odoo 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 Odoo 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)

oca.recipe.odoo.utils.next(iterator)

Python2 compatibility of iterators

oca.recipe.odoo.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('')
()

The return value is guaranteed not to be a single string:

>>> option_splitlines('single')
('single',)

For convenience, None is accepted:

>>> option_splitlines(None)
()

oca.recipe.odoo.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

oca.recipe.odoo.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

oca.recipe.odoo.utils.use_or_open(provided, path, *open_args)

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.

Subpackages

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