License: LGPL-3

setuptools-odoo is a library to help packaging Odoo addons with setuptools. It mainly populates the usual keywords from the Odoo manifest files.

It enables the packaging and distribution of Odoo addons using standard python infrastructure (ie setuptools, pip, wheel, and pypi).



From version 1.0.0b7 onwards, the package name structure is odoo<series>-addon-<addon_name>. Before it was odoo-addon-<addon_name>. This backward-incompatible change was necessary to enable easier publishing to pypi or other wheelhouses as discussed in issue 6.

If you need to continue working with the previous naming scheme for some time, set the following environment variable SETUPTOOLS_ODOO_LEGACY_MODE=1. This legacy scheme will be supported until version 1.1.

It is highly recommanded to remove .eggs and *.egg-info directories from editable source directories before using this new version.


The documentation below applies to Odoo 10+

Odoo 8 and 9 are supported too, with the help of odoo-autodiscover. You must replace in the text below odoo.addons (the namespace) and odoo/addons (the directory) by odoo_addons.

Packaging a single addon

To be packaged with this library, the addon source code must have the following structure (assuming the addon is named <addon_name>):

where odoo/ and odoo/addons/ are standard python namespace package declaration


and where has the following content:

import setuptools


The usual setup() keyword arguments are computed automatically from the Odoo manifest file ( and contain:

  • name: the package name, odoo<series>-addon-<addon_name>
  • version: the version key from the manifest
  • description: the summary key from the manifest if it exists otherwise the name key from the manifest
  • long_description: the content of the README.rst file if it exists, otherwise the description key from the manifest
  • url: the website key from the manifest
  • license: the license key from the manifest
  • packages: autodetected packages
  • namespace_packages: ['odoo', 'odoo.addons']
  • zip_safe: False
  • include_package_data: True
  • install_requires: dependencies to Odoo, other addons (except official odoo addons, which are brought by the Odoo dependency) and python libraries.

Then, the addon can be deployed and packaged with usual or pip commands such as:

python install
python develop
python bdist_wheel
pip install .
pip install -e .
pip install odoo<8|9|10>-addon-<addon name>

For Odoo 10, simply run Odoo normally with the odoo command. The addons-path will be automatically populated with all places providing odoo addons installed with this method.

For Odoo 8 or 9 start Odoo using the odoo-server-autodiscover or scripts provided in the odoo-autodiscover package.

It is of course highly recommanded to run all this inside a virtualenv.

Packaging multiple addons

Addons that are intended to be reused or depended upon by other addons MUST be packaged individually. When preparing a project for a specific customer, it is common to prepare a collection of addons that are not intended to be depended upon by addons outside of the project. setuptools-odoo provides tools to help you do that.

To be packaged with this library, your project must be structured according to the following structure:

where has the following content:

import setuptools

    name='<your project package name>',
    version='<your version>',
    # ...any other setup() keyword

The following setup() keyword arguments are computed automatically from the Odoo manifest files ( and contain:

  • packages: autodetected packages
  • namespace_packages: ['odoo', 'odoo.addons']
  • zip_safe: False
  • include_package_data: True
  • install_requires: dependencies on Odoo, any depending addon not found in the addons directory, and external python dependencies.

Controlling setuptools-odoo behaviour

It is possible to use a dictionary instead of True for the odoo_addon and odoo_addons keywords, in order to control their behaviour.

The following keys are supported:

  • depends_override, used to precisely control odoo addons dependencies. Its value must be a dictionary mapping addon names to a package requirement string.
  • external_dependencies_override, used to precisely control python external dependencies. Its value must be a dictionary with one python key, with value a dictionary mapping python external dependencies to python package requirement strings.
  • odoo_version_override, used to specify which Odoo series to use (8.0, 9.0, 10.0, etc) in case an addon version does not start with the Odoo series number. Use this only as a last resort, if you have no way to correct the addon version in its manifest.

For instance, if your module requires at least version of the connector addon, as well as at least version 0.5.5 of py-Asterisk, your would look like this:

import setuptools

        'depends_override': {
            'connector': 'odoo10-addon-connector>=',
        'external_dependencies_override': {
            'python': {
                'Asterisk': 'py-Asterisk>=0.5.5',

setuptools-odoo-make-default helper script

Since reusable addons are generally not structured using the namespace package but instead collected in a directory with each subdirectory containing an addon, this package provides the setuptools-odoo-make-default script which creates a default for each addon according to the following structure:

setup/addon1/odoo/addons/<addon1_name> -> ../../../../<addon1_name>
setup/addon2/odoo/addons/<addon2_name> -> ../../../../<addon2_name>


setuptools-odoo does its best to detect if an addon has changed compared to the version indicated in it’s manifest. To this end it explores the git log of the addon subtree.

If the last change to the addon corresponds to the version number in the manifest, it is used as is for the python package version. Otherwise a counter is incremented for each commit and the resulting version number has the following form: [8|9].0.x.y.z.99.devN, N being the number of git commits since the version change.

This scheme is compliant with the accepted python versioning scheme documented in PEP 440.

The 99 suffix is there to make sure it is considered as posterior to x.y.z. (.postN is ignored by pip, as specified in PEP 440, and x.y.z.devN is considered anterior to x.y.z.).


for pip to install a developmental version, it must be invoked with the –pre option.

Helper API

setuptools-odoo exposes the following public API.



Should you have a use case for using the setuptools-odoo internals, get in touch so we can review your needs and expose a clean API.



Many thanks to Daniel Reis who cleared the path, and Laurent Mignon who convinced me it was possible to do it using standard Python setup tools and had the idea of the odoo_addons namespace package.


1.0.2 (2017-??-??)

  • [IMP] update base addons list for Odoo 10.0
  • [IMP] when setuptools extends a list-type keyword, prevent duplicate items

1.0.1 (2017-04-08)

  • [ADD] add license classifier for the licenses commonly used in OCA

1.0.0 (2017-04-07)

  • [ADD] support the brand new Framework :: Odoo classifier

1.0.0rc4 (2017-02-21)

  • [FIX] avoid setuptools-git version 1.2 as it is broken for our use case

1.0.0rc3 (2017-01-14)

  • [FIX] git based automatic postversioning was not working in situations where the manifest was renamed (eg when renaming to
  • [IMP] support author email: since the Odoo manifest has no such concept this is currently just a special case when OCA is in the authors

1.0.0rc2 (2016-10-07)

  • [IMP] 10.0 addons now depend on the specific Odoo version again (>=10.0, <10.1dev)

1.0.0rc1 (2016-10-03)

  • [IMP] Odoo 10.0 support with addons in the odoo.addons namespace.
  • [IMP] update base addons list for Odoo 9.0 and 10.0rc1

1.0.0b7 (2016-09-22)

  • [IMP] add support for Odoo 10, drop support which has never been supported by Odoo.
  • [IMP] BREAKING: package names are now constructed along the following scheme: odoo{series}-addon-{addon_name} where series is 8, 9 or 10.

1.0.0b6 (2016-08-23)

  • [IMP] the odoo_addon and odoo_addons keyword now extend list keywords such as install_requires if they are present in (previously, it left them alone); this is useful to create a package that contains odoo addons in addition to other python packages
  • [IMP] allow None as value for depends_override to disable the addition of an addon present in ‘depends’ key to ‘install_requires’
  • [IMP] check if Odoo version is supported also in presence of odoo_version_override
  • [ADD] preliminary OpenErp 7.0 support
  • [ADD] –odoo-version-override to setuptools-odoo-make-default to use when there is no practical way to normalize addons versions
  • [FIX] when using odoo_version_override, make sure the package version starts with the Odoo version, otherwise dependencies from other packages do not work
  • [UPD] refresh base addons list for odoo 9c with new modules added over the last months

1.0.0b5 (2016-05-03)

  • [FIX] fix bug of previous release that prevented the packaging of a single auto_install addon

1.0.0b4 (2016-04-06)

  • [UPD] pycrypto in external dependencies map
  • [ADD] setuptools-odoo-make-default now ignores addons listed in .setuptools-odoo-make-default-ignore; this is useful when some addons are manually included in another package (such as autoinstallable glue modules)
  • [ADD] setuptools-odoo-make-default now generates README and .setuptools-odoo-make-default-ignore files at the root of the setup directory
  • [IMP] the odoo_addon setup keyword now accepts several addons in the odoo_addons namespace, provided exactly one is installable and not auto installable. This is meant to package an addon together with one or more auto_installable glue modules.

1.0.0b3 (2016-02-10)

  • [ADD] mechanism to specify which Odoo version to use in dependencies (8.0, 9.0) in case some addons to be packaged have non-standard version numbers
  • [ADD] support for addons without version number in their manifest (unfortunately there are some in the wild...)

1.0.0b2 (2016-01-26)

  • [ADD] mechanism to override dependencies, to allow addon authors to require minimal versions of dependent odoo addons, and to control external python dependencies

1.0.0b1 (2015-12-29)

  • [FIX] fix postversioning when running outside git directory
  • [IMP] additional mappings for python external dependencies
  • [ADD] make_pkg_name public api to convert an addon name to a python package name
  • [ADD] make_pkg_requirement public api to obtain a valid package requirement for a given addon (same as make_pkg_name but includes requirement for the correct Odoo series)
  • [FIX] crash in case a previous commit had a bad

Developer instructions

How to run tests

  • run tox (if not installed apt-get install tox)

How to build the documentation

Documentation is built automatically at

To build it locally:

  • pip install -e .
  • pip install sphinx
  • cd docs
  • make html

How to release

  • update changelog in CHANGES.rst, referring to the next version
  • python check –restructuredtext
  • commit everything
  • make sure tests pass!
  • git tag <version>, where <version> is PEP 440 compliant
  • git push –tags

Uploading of tagged versions to pypi will be taken care of by travis.