Addons provided with main software should be first

Bug #1246822 reported by Georges Racinet
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenERP buildout recipe
Fix Released
Medium
Unassigned

Bug Description

In case the buildout configuration is made of a full packed OpenERP tarball (such as nightly releases) plus an additional addons directory,
one can get the following error in initial phase of startup:

2013-10-31 16:33:18,341 13185 ERROR xxxx openerp: Failed to initialize database `xxxx`.
Traceback (most recent call last):
  File "build/parts/openerp-7.0-20130824-231042/openerp/cli/server.py", line 97, in preload_registry
    db, registry = openerp.pooler.get_db_and_pool(dbname,update_module=update_module)
  File "build/parts/openerp-7.0-20130824-231042/openerp/pooler.py", line 33, in get_db_and_pool
    registry = RegistryManager.get(db_name, force_demo, status, update_module)
  File "build/parts/openerp-7.0-20130824-231042/openerp/modules/registry.py", line 192, in get
    update_module)
  File "build/parts/openerp-7.0-20130824-231042/openerp/modules/registry.py", line 218, in new
    openerp.modules.load_modules(registry.db, force_demo, status, update_module)
  File "build/parts/openerp-7.0-20130824-231042/openerp/modules/loading.py", line 345, in load_modules
    processed = load_marked_modules(cr, graph, states_to_load, force, status, report, loaded_modules, update_module)
  File "build/parts/openerp-7.0-20130824-231042/openerp/modules/loading.py", line 256, in load_marked_modules
    loaded, processed = load_module_graph(cr, graph, progressdict, report=report, skip_modules=loaded_modules, perform_checks=perform_checks)
  File "build/parts/openerp-7.0-20130824-231042/openerp/modules/loading.py", line 159, in load_module_graph
    load_openerp_module(package.name)
  File "build/parts/openerp-7.0-20130824-231042/openerp/modules/module.py", line 415, in load_openerp_module
    getattr(sys.modules['openerp.addons.' + module_name], info['post_load'])()
  File "build/parts/openerp-7.0-20130824-231042/openerp/addons/web/http.py", line 628, in wsgi_postload
    openerp.wsgi.register_wsgi_handler(Root())
  File "build/parts/openerp-7.0-20130824-231042/openerp/addons/web/http.py", line 517, in __init__
    self.load_addons()
  File "build/parts/openerp-7.0-20130824-231042/openerp/addons/web/http.py", line 580, in load_addons
    m = __import__('openerp.addons.' + module)
  File "build/parts/openerp-7.0-20130824-231042/openerp/modules/module.py", line 133, in load_module
    mod = imp.load_module('openerp.addons.' + module_part, f, path, descr)
  File "build/parts/openerp-7.0-20130824-231042/openerp/addons/account/__init__.py", line 23, in <module>
    import account
  File "build/parts/openerp-7.0-20130824-231042/openerp/addons/account/account.py", line 34, in <module>
    import openerp.addons.decimal_precision as dp
AttributeError: 'module' object has no attribute 'decimal_precision'

This is present in both branches of the recipe.
Removing the additional addons option in the configuration file effectively cures the problem, and one can install the account module.

Configurations that keep the three server, addons and web separate (e.g. on bzr branches) are not affected. This case is (obviously) much more frequent, this problem must have been there for a long while and may not be present in pre-7.0 OpenERP versions.

Related branches

Revision history for this message
Georges Racinet (gracinet) wrote :

 I thought for a while it was the recipe's fault, because changing the ordering of addons_path in etc/openerp.cfg solves the problem.
But then I saw that reproduction is not as systematic as reported and could track back the origin of the problem to the fact that the specific addon does this:

  import decimal_precision as dp

which is now incorrect (and incorrectly reported as non harmful in openerp.modules.module comments)

That being said, it's probably better to put the main addons path first in addons_path, instead of at the end as is currently the case.
The import is done from the web module, with the following loop:

        for addons_path in openerp.modules.module.ad_paths:
            for module in sorted(os.listdir(str(addons_path))):

Somehow it looks saner and more robust to do all OpenERP standard modules first, then all additional ones, instead of relying on depency resolving passing through layers keeping potential shadowings for historical reasons.

But there's no need to do that as an emergency, nor in the stable branch.

Changed in anybox.recipe.openerp:
importance: Critical → Low
milestone: 1.7.4 → 1.8.2
Revision history for this message
Georges Racinet (gracinet) wrote :

Actually the ordering of addons paths has changed between 1.7.0 and 1.7.1 as an unwanted side effect of some refactor.
This can impact code that expects at import time that openerp standard addons have already been imported. The sooner it'll be fixed, the less code in the wild will depend on the inverted behaviour

(The arbitrary import from http.py module is a very bad thing, but it's not ours to fix).

Note also that this an area where there can be a difference between split setup (server + addons + web) and the nightly releases

Changed in anybox.recipe.openerp:
importance: Low → Medium
milestone: 1.8.2 → 1.7.4
status: New → Fix Committed
summary: - import error with nightly + additional addon
+ Addons provided with main software should be first
Revision history for this message
Georges Racinet (gracinet) wrote :

Renamed as "Addons provided with main software should be first"
In the recipe internal terminology, main software means the unit (tarball, branch or local) in which openobject-server sits.
In the case of nightlies, it'll have the whole of openobject-addons and openobject-web

Changed in anybox.recipe.openerp:
milestone: 1.7.4 → 1.8.3
Changed in anybox.recipe.openerp:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.