Addons provided with main software should be first
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/
db, registry = openerp.
File "build/
registry = RegistryManager
File "build/
update_module)
File "build/
openerp.
File "build/
processed = load_marked_
File "build/
loaded, processed = load_module_
File "build/
load_
File "build/
getattr(
File "build/
openerp.
File "build/
self.
File "build/
m = __import_
File "build/
mod = imp.load_
File "build/
import account
File "build/
import openerp.
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
Changed in anybox.recipe.openerp: | |
milestone: | 1.7.4 → 1.8.3 |
Changed in anybox.recipe.openerp: | |
status: | Fix Committed → Fix Released |
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: os.listdir( str(addons_ path))) :
for module in sorted(
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.