anybox / anybox.recipe.odoo Goto Github PK

Referring to HEAD and FETCH_HEAD crash the buildout recipe

Since Odoo source is quite unstable, using SHAs are the only viable way to guarantee behaviour remains as intended.

Our recipes make strong usage of SHAs and HEAD to guarantee code stability.
Please bring back this functionality as this is a severe regression for us.

We cannot solve these problems by using tags since for most projects, we don't have the rights to create tags and defaulting to the newest commit of a branch doesn't guarantee stability.

33d67a9#commitcomment-8823975

I have below file on my localhost, but am getting the error that port is already in use, even though it's not. When I run Odoo in my "old" way, it works, and it also doesn't matter which port I choose.

I have modified Odoo source to print out when it's trying to bind to a port, and I notice that it's trying to bind twice. The first time works, but the second time fails.

Is there something wrong in my buildout.cfg that makes Odoo to bind to the port twice?

[buildout]
parts = odoo
find-links =
    http://download.gna.org/pychart/
    http://github.com/aeroo/aeroolib/tarball/master#egg=aeroolib
versions = versions
extensions = gp.vcsdevelop
newest = false
eggs-directory=/home/antiflu/Code/buildout/global-eggs

[odoo]
release = 8.0
recipe = anybox.recipe.odoo:server
eggs =
    gevent
    inouk.recipe.odoo_cmd

version = path /opt/odoo8

merges = 

[versions]

[odoo]
eggs += pyserial

vcs-clear-retry = True

options.xmlrpc_port = 11069
options.logfile = /var/log/odoo/odoo8.log
options.workers = 2
options.db_host = localhost
options.db_name = testing
options.db_port = 5432
options.db_user = odoo8
options.db_password = odoo8
options.xmlrpc = True
options.xmlrpcs = False
options.netrpc = False
options.without_demo = True
options.limit_time_cpu = 36000
options.limit_time_real = 72000
options.longpolling_port = 8170
options.log_handler = :DEBUG,werkzeug:CRITICAL,openerp.service.server:INFO
options.log_level = debug
options.lang = nl_NL

The extract-downloads-to is a useful option that allows to aggregate sources into a self-contained archive.
However, its current implementation does not allows to use it with the merge option. This limitation is mainly due to the fact that whatever of the command, the system always tries to retrieve main software, addons and merges in offline mode. (The last one is not compatible with the offline mode).

I propose to modify the extract-download-to command to isolate the process from others steps required by a simple installation. In this way the install and freeze-to commands will not be enforced by the extract-download-to command. After this change, it will be possible to extract the sources at any time and build distributions that include merges in a self-contained archive and deployable on a server without access to VCS systems.

This is a special case of issue #2 which qualifies as a bug (infrequent)

Actually, even tags used in the buildout to freeze get replaced by their SHA (which at least cannot be garbage collected).

Now, SHAs can be fetched only if they are reachable from the HEAD of remote repo (typically master), which means that currently tags on feature branches cannot be used at all in the freeze/extract part of the process. This is not a projection, it just happened on a real project at Anybox.

Probably due to the renamings and standard setup.py arcanes, the template for upgrade.py seems to be missing in the released anybox.recipe.odoo 1.9.0 (not from anybox.recipe.openerp).

This is problematic for a first execution. Example seen in automated tests of anybox-odoo-hosts:

  File "/opt/anybox/lib/python/anybox.recipe.odoo-1.9.0-py2.7.egg/anybox/recipe/odoo/base.py", line 859, in install
    self._install_startup_scripts()
  File "/opt/anybox/lib/python/anybox.recipe.odoo-1.9.0-py2.7.egg/anybox/recipe/odoo/server.py", line 534, in _install_startup_scripts
    self._register_upgrade_script(qualified_name)
  File "/opt/anybox/lib/python/anybox.recipe.odoo-1.9.0-py2.7.egg/anybox/recipe/odoo/server.py", line 318, in _register_upgrade_script
    shutil.copy(self.template_upgrade_script, script_source_path)
  File "/usr/lib/python2.7/shutil.py", line 119, in copy
    copyfile(src, dst)
  File "/usr/lib/python2.7/shutil.py", line 82, in copyfile
    with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: '/opt/anybox/lib/python/anybox.recipe.odoo-1.9.0-py2.7.egg/anybox/recipe/odoo/upgrade.py.tmpl'

We were able to specify commits on branches, in order to freeze the changes in a recipe. This is useful in case of branches breaking with later commits. It also forces a change in the pull request code to need a change in the recipe with forcing us, internally, to do a merge proposal and have it tested by CI.

Example:

merges =
          ; Partner Contact
          ;  https://github.com/OCA/partner-contact/pull/75
          git https://github.com/savoirfairelinux/partner-contact.git      ../../partner-contact   7.0_fix_function_partner_import_issue:commits/84bf0e24ca12474b222f8e4dd7355d11cdf0375c

This seems to work fine for us, but to make sure there are no regressions, could this be tested, ex:

Testing merges of branch1:commits/1234abcd

It seems 1.9.2 recipe does not include this commit
968735b

Is it possible to generate a new version with this commit ?

Thanks a lot

Workaround: pin psutil = 2.1.1 in [versions]

This creates errors like this:

2015-06-15 17:29:38,128 6166 ERROR ? openerp.service.server: Worker (6166) Exception occured, exiting...
Traceback (most recent call last):
  File "/opt/odoo8/git/odoo/openerp/service/server.py", line 732, in run
    self.process_limit()
  File "/opt/odoo8/git/odoo/openerp/service/server.py", line 687, in process_limit
    rss, vms = psutil.Process(os.getpid()).get_memory_info()
AttributeError: 'Process' object has no attribute 'get_memory_info'

Because the API changed.

psutil is frozen at 2.1.1 in the odoo requirements.txt, the recipe should respect that.

More than an issue this is a support request, on the time we have been using the buildout recipe we often have been to deal with buildout script crashing because of [Errno 104] Connection reset by peer during the eggs download phase.

I know is a problem with our internet connection that had a temporal issue communicating with pip database, but unfortunately we cannot do anything to improve the situation on the technical side.

Until now the way we deal with the problem is restarting the buildout compilation as many times as needed for a successful build. Unfortunately that's very tie consuming and not the ideal behavior.

How do you deal with this situation? Is there any buildout option that could help wit this?

./bin/upgrade_odoo --log-file=~/test.log --log-level=info --console-log-level=debug -d web

The test.log is empty.

Is that normal ?

Hi,
#50 failed building the documentation: https://buildbot.anybox.fr/builders/anybox.recipe.odoo/builds/59/steps/sphinx/logs/stdio

I suggest to build documentation on travis as well, to let developer know when create a PR if it will pass or failed on buildbot.

I hope the html setting isn't environment dependent ?

Today, trying to run a "yesterday working" buildout, I get

$ bin/buildout 
Found command 'git' at '/usr/bin/git'
https://github.com/anybox/anybox.recipe.odoo
Clone in ./a.r.openerp exists, and has correct URL (https://github.com/anybox/anybox.recipe.odoo)
Updating ./a.r.openerp clone (to a.r.openerp-1.9)
a.r.odoo-1.9.0
a.r.openerp-1.9.0
4c8c77685a5559506068a6dcb8e84b22470bfef9
61f7822e011406185b794c6635f82010f535d774
  origin/HEAD -> origin/master
  origin/a.r.openerp-1.8
  origin/a.r.openerp-1.9
  origin/master
8eb92a1d6b031ec411959fcab333d9b4222faf25
f269a33d2342c97d9fc8b9ea6b6e001b100dd479
456605a9cf49813f0fa44f7183e8f45e952343a2
8eb92a1d6b031ec411959fcab333d9b4222faf25
Develop: '/home/elbati/workspace/odoo/progetti/agilebg/git/agilebg/a.r.openerp'
Traceback (most recent call last):
  File "/tmp/tmpTrNHJK", line 14, in <module>
    exec(compile(f.read(), '/home/elbati/workspace/odoo/progetti/agilebg/git/agilebg/a.r.openerp/setup.py', 'exec'))
  File "/home/elbati/workspace/odoo/progetti/agilebg/git/agilebg/a.r.openerp/setup.py", line 51, in <module>
    'bzr' : ['bzr'] },
  File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "build/bdist.linux-i686/egg/setuptools/command/develop.py", line 32, in run
  File "build/bdist.linux-i686/egg/setuptools/command/develop.py", line 132, in install_for_development
  File "build/bdist.linux-i686/egg/setuptools/command/easy_install.py", line 695, in process_distribution
  File "build/bdist.linux-i686/egg/setuptools/command/develop.py", line 160, in install_egg_scripts
  File "build/bdist.linux-i686/egg/setuptools/command/develop.py", line 173, in install_wrapper_scripts
TypeError: must be type, not classobj
While:
  Installing.
  Processing develop directory '/home/elbati/workspace/odoo/progetti/agilebg/git/agilebg/a.r.openerp'.

An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
  File "/home/elbati/workspace/odoo/progetti/agilebg/git/agilebg/eggs/zc.buildout-2.5.0-py2.7.egg/zc/buildout/buildout.py", line 1992, in main
    getattr(buildout, command)(args)
  File "/home/elbati/workspace/odoo/progetti/agilebg/git/agilebg/eggs/zc.buildout-2.5.0-py2.7.egg/zc/buildout/buildout.py", line 528, in install
    installed_develop_eggs = self._develop()
  File "/home/elbati/workspace/odoo/progetti/agilebg/git/agilebg/eggs/zc.buildout-2.5.0-py2.7.egg/zc/buildout/buildout.py", line 770, in _develop
    zc.buildout.easy_install.develop(setup, dest)
  File "/home/elbati/workspace/odoo/progetti/agilebg/git/agilebg/eggs/zc.buildout-2.5.0-py2.7.egg/zc/buildout/easy_install.py", line 1020, in develop
    call_subprocess(args)
  File "/home/elbati/workspace/odoo/progetti/agilebg/git/agilebg/eggs/zc.buildout-2.5.0-py2.7.egg/zc/buildout/easy_install.py", line 160, in call_subprocess
    % repr(args)[1:-1])
Exception: Failed to run command:
'/home/elbati/workspace/odoo/progetti/agilebg/git/agilebg/sandbox/bin/python', '/tmp/tmpTrNHJK', '-q', 'develop', '-mN', '-d', '/home/elbati/workspace/odoo/progetti/agilebg/git/agilebg/develop-eggs/tmpoQ_V6dbuild'

The environment is created like described at http://pythonhosted.org/anybox.recipe.odoo/first_steps.html#bootstrapping-the-buildout and I am using a.r.openerp-1.9 version of the recipe

Does anybody know what caused it or how to investigate it?

Thanks

To reproduce

I use recipe anybox.recipe.odoo-1.9.2 and #88 for v10

I also use --dev argument with option all

Watchdog lib is installed, so server restart when file is modified.
path execution is:

/usr/bin/python bin/start_openerp --dev=all

but when server restart the path becomes:

python /workspace/parts/odoo/odoo-bin -c /workspace/etc/openerp.cfg --dev=all

So, all libs installed with buildout are no more available (like passlib)

How it should works

I suppose, we should keep the same path

The question is, how can we do that ?

Is there somebody in trouble with that ?

ping @archetipo @gracinet @StefanRijnhart

The generated conf file for the web part should be a python format

Double quote are missing around module path (addons_path)

After this commit
odoo/odoo@9e64f9f
I guess the recipe needs changes

Including Pillow==3.4.0 in your dependencies will crash buildout. I get the following traceback...

Traceback (most recent call last):
File "", line 1, in
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 2279, in main
**kw
File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
dist.run_commands()
File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 411, in run
self.easy_install(spec, not self.no_deps)
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 653, in easy_install
return self.install_item(None, spec, tmpdir, deps, True)
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 698, in install_item
dists = self.install_eggs(spec, download, tmpdir)
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 879, in install_eggs
return self.build_and_install(setup_script, setup_base)
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 1118, in build_and_install
self.run_setup(setup_script, setup_base, args)
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 1104, in run_setup
run_setup(setup_script, args)
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/sandbox.py", line 257, in run_setup
raise
File "/usr/lib/python2.7/contextlib.py", line 35, in exit
self.gen.throw(type, value, traceback)
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/sandbox.py", line 199, in setup_context
yield
File "/usr/lib/python2.7/contextlib.py", line 35, in exit
self.gen.throw(type, value, traceback)
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/sandbox.py", line 170, in save_modules
saved_exc.resume()
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/sandbox.py", line 145, in resume
six.reraise(type, exc, self._tb)
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/sandbox.py", line 158, in save_modules
yield saved
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/sandbox.py", line 199, in setup_context
yield
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/sandbox.py", line 254, in run_setup
_execfile(setup_script, ns)
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/sandbox.py", line 49, in _execfile
exec(code, globals, locals)
File "/tmp/easy_install-EgOYDL/Pillow-3.4.0/setup.py", line 753, in

File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
dist.run_commands()
File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/command/bdist_egg.py", line 169, in run
cmd = self.call_command('install_lib', warn_dir=0)
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/command/bdist_egg.py", line 155, in call_command
self.run_command(cmdname)
File "/usr/lib/python2.7/distutils/cmd.py", line 326, in run_command
self.distribution.run_command(command)
File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "/opt/home_virtualenv/lib/python2.7/site-packages/setuptools/command/install_lib.py", line 11, in run
self.build()
File "/usr/lib/python2.7/distutils/command/install_lib.py", line 111, in build
self.run_command('build_ext')
File "/usr/lib/python2.7/distutils/cmd.py", line 326, in run_command
self.distribution.run_command(command)
File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "/usr/lib/python2.7/distutils/command/build_ext.py", line 340, in run
self.build_extensions()
File "/tmp/easy_install-EgOYDL/Pillow-3.4.0/setup.py", line 521, in build_extensions

ValueError: jpeg is required unless explicitly disabled using --disable-jpeg, aborting
An error occurred when trying to install /tmp/tmpiI6t2oget_dist/Pillow-3.4.0.zip. Look above this message for any errors that were output by easy_install.
While:
Installing odoo.
Getting distribution for 'Pillow==3.4.0'.

An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
File "/opt/home/eggs/zc.buildout-2.9.5-py2.7.egg/zc/buildout/buildout.py", line 2123, in main
getattr(buildout, command)(args)
File "/opt/home/eggs/zc.buildout-2.9.5-py2.7.egg/zc/buildout/buildout.py", line 796, in install
installed_files = self[part]._call(recipe.install)
File "/opt/home/eggs/zc.buildout-2.9.5-py2.7.egg/zc/buildout/buildout.py", line 1553, in _call
return f()
File "/opt/home/a.r.odoo/anybox/recipe/odoo/base.py", line 1123, in install
self.install_requirements()
File "/opt/home/a.r.odoo/anybox/recipe/odoo/base.py", line 566, in install_requirements
eggs_recipe.install()
File "/opt/home/eggs/zc.recipe.egg-2.0.4-py2.7.egg/zc/recipe/egg/egg.py", line 193, in install
reqs, ws = self.working_set()
File "/opt/home/eggs/zc.recipe.egg-2.0.4-py2.7.egg/zc/recipe/egg/egg.py", line 82, in working_set
allow_hosts=self.allow_hosts,
File "/opt/home/eggs/zc.recipe.egg-2.0.4-py2.7.egg/zc/recipe/egg/egg.py", line 135, in _working_set
allow_hosts=allow_hosts)
File "/opt/home/eggs/zc.buildout-2.9.5-py2.7.egg/zc/buildout/easy_install.py", line 913, in install
return installer.install(specs, working_set)
File "/opt/home/eggs/zc.buildout-2.9.5-py2.7.egg/zc/buildout/easy_install.py", line 665, in install
for dist in self._get_dist(requirement, ws):
File "/opt/home/eggs/zc.buildout-2.9.5-py2.7.egg/zc/buildout/easy_install.py", line 563, in _get_dist
dists = [_move_to_eggs_dir_and_compile(dist, self._dest)]
File "/opt/home/eggs/zc.buildout-2.9.5-py2.7.egg/zc/buildout/easy_install.py", line 1699, in _move_to_eggs_dir_and_compile
[tmp_loc] = glob.glob(os.path.join(tmp_dest, '*'))
ValueError: need more than 0 values to unpack

This is fortunately catched by unit tests, with several errors like this one:

======================================================================
ERROR: test_prepare_frozen_buildout_gp_vcsdevelop (anybox.recipe.odoo.tests.test_freeze.TestFreeze)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/gracinet/odoo/recipe/a.r.odoo/anybox/recipe/odoo/tests/test_freeze.py", line 145, in test_prepare_frozen_buildout_gp_vcsdevelop
    self.recipe._prepare_frozen_buildout(conf)
  File "/home/gracinet/odoo/recipe/a.r.odoo/anybox/recipe/odoo/base.py", line 1166, in _prepare_frozen_buildout
    for raw, _, _, abs_path in self._get_gp_vcs_develops():
  File "/home/gracinet/odoo/recipe/a.r.odoo/anybox/recipe/odoo/base.py", line 1152, in _get_gp_vcs_develops
    parsed = pip.req.parse_editable(raw)
AttributeError: 'module' object has no attribute 'parse_editable'
-------------------- >> begin captured logging << --------------------
anybox.recipe.odoo.base: INFO: Created downloads/ directory
anybox.recipe.odoo.base: INFO: Created etc/ directory
--------------------- >> end captured logging << ---------------------

Will be great if we can add an option to vcs-revert so we can revert the merges before update repositories.

Currently this is the user case, just pasting relevant parts from my buildout recipe:

[buildout]
parts = openerp
versions = versions
find-links = http://download.gna.org/pychart/

[openerp]
recipe = anybox.recipe.openerp[bzr]:server
version = git https://github.com/OCA/OCB server master

addons = git http://gitlab.openpyme.mx/l10n_mx/facturacion.git parts/l10n_mx master
         git https://github.com/OCA/account-financial-reporting.git parts/account_financial_reporting 7.0
         git http://gitlab.openpyme.mx/l10n_mx/l10n_mx.git parts/l10n_mx master group=l10n_mx
         git https://github.com/OCA/connector.git parts/connector 7.0
         git https://github.com/OpenPymeMx/connector-drupal.git parts/drupal-connector nsgt
         local parts/server/addons 

merges = 
         git http://gitlab.openpyme.mx/l10n_mx/facturacion.git parts/l10n_mx signals
         git http://gitlab.openpyme.mx/l10n_mx/facturacion.git parts/l10n_mx workflow

vcs-revert = on-merge

As you can see there is a repo named facturacion where we are merging two WIP branches. First time we run the buildout.py there is no problem, everything works ok, but if we commit a bug fix to master branch and then we try to run the buildout.py again we got an error because facturacion repo no longer can be fast forwarded.

I know for sure that there is no conflicts on the commited bug fix and the two WIP branches, in fact if manually reset git branch to a prev commit and re run the buildout.py everything works as expected.

Follow-up after PR #78 (see there for more details)

• we'd like not to query remotes if refspec is a locally known tag, with an option to force the querying
• the logic to avoid remote queries needs to be refactored.

Not sure at this point if a potential integration with git-aggregator (see PR #79) would make this obsolete or not

Input:

addons = ...
         pr_fakevcs http://repo2.example stdln rev2 group=stdl
         pr_fakevcs http://repo2.example stdln2 rev2 group=stdl

Expected output in the generated release.cfg:

addons = ...
         local stdl

Actual result:

addons = ...
         local stdl
         local stdl

Hi,

I want to propose @StefanRijnhart as maintainer of anybox.recipe.odoo. @StefanRijnhart actively supports the development of this recipe for a long time.

cc @petrus-v @gracinet

lmi

anybox.recipe.odoo must ensure develop-eggs directory is well created before calling develop method

Using new zc.buildout version (2.9.3) with no 'develop' or 'vcs-develop' directives in buildout.cfg leads to a weird issue : OSError: [Errno 2] No such file or directory: '/mypath/develop-eggs/tmpg0yP_Xbuild'

It seems develop-eggs directory is not created (and cannot be ?) so the recipe should check it exists before making any call to develop

The URLs are still not correct, should go to nighly.odoo.com/old
Wasn't seen immediately on the buildbots, because/thanks to the cache, but got it afer purging some buildslaves.

(that's minor, I'd say)

Use case:
I have a repository under addons and I want to merge a branch from another repository into it, at a specific revision.
This is intended to prevent to silently include unexpected change to the instance.

Example:

addons = [...]
         git http://github.com/OCA/reporting-engine.git parts/reporting-engine da1e961a2787c3672131d881e8792bfb9a6a2ec4 branch=9.0
         [...]

and

merges += git https://github.com/faide/reporting-engine.git parts/reporting-engine 90bd61d3e12270c860c4fcbdf47d6a11801b1242 branch=report_py3o

This configuration is supposed to add changes coming from
OCA/reporting-engine#73
at the current state (rev 90bd61d3e12270c860c4fcbdf47d6a11801b1242)

Running buildout, I get

anybox.recipe.openerp.vcs.git: /home/elbati/workspace/odoo/instances/demo9-community/parts/reporting-engine> call ['git', 'pull', '--no-edit', 'https://github.com/faide/reporting-engine.git', '90bd61d3e12270c860c4fcbdf47d6a11801b1242']
error: no such remote ref 90bd61d3e12270c860c4fcbdf47d6a11801b1242
While:
  Updating odoo.

An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
  File "/home/elbati/workspace/odoo/instances/demo9-community/eggs/zc.buildout-2.5.3-py2.7.egg/zc/buildout/buildout.py", line 1995, in main
    getattr(buildout, command)(args)
  File "/home/elbati/workspace/odoo/instances/demo9-community/eggs/zc.buildout-2.5.3-py2.7.egg/zc/buildout/buildout.py", line 636, in install
    installed_files = self[part]._call(update)
  File "/home/elbati/workspace/odoo/instances/demo9-community/eggs/zc.buildout-2.5.3-py2.7.egg/zc/buildout/buildout.py", line 1410, in _call
    return f()
  File "/home/elbati/workspace/odoo/instances/demo9-community/a.r.openerp/anybox/recipe/openerp/base.py", line 862, in install
    self.retrieve_merges()
  File "/home/elbati/workspace/odoo/instances/demo9-community/a.r.openerp/anybox/recipe/openerp/base.py", line 715, in retrieve_merges
    **options)
  File "/home/elbati/workspace/odoo/instances/demo9-community/a.r.openerp/anybox/recipe/openerp/vcs/__init__.py", line 25, in get_update
    return repo(vcs_type, target_dir, url, **options)(revision)
  File "/home/elbati/workspace/odoo/instances/demo9-community/a.r.openerp/anybox/recipe/openerp/vcs/base.py", line 111, in __call__
    self.get_update(revision)
  File "/home/elbati/workspace/odoo/instances/demo9-community/a.r.openerp/anybox/recipe/openerp/vcs/git.py", line 298, in get_update
    return self.merge(revision)
  File "/home/elbati/workspace/odoo/instances/demo9-community/a.r.openerp/anybox/recipe/openerp/vcs/git.py", line 398, in merge
    self.log_call(cmd)
  File "/home/elbati/workspace/odoo/instances/demo9-community/a.r.openerp/anybox/recipe/openerp/vcs/git.py", line 147, in log_call
    return callwith(cmd, **kw)
  File "/usr/lib/python2.7/subprocess.py", line 541, in check_call
    raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '['git', 'pull', '--no-edit', 'https://github.com/faide/reporting-engine.git', '90bd61d3e12270c860c4fcbdf47d6a11801b1242']' returned non-zero exit status 1

Is this solvable?

Thanks

Hello,

with the new Docker rage, it's now not always an issue to connect to postgres with the postgres user. Official PG image provide a postgres user and that's not a problem if the PG server is containerized.

So I would like to optionally be able to skip the PG user check here:
https://github.com/anybox/anybox.recipe.odoo/blob/master/anybox/recipe/odoo/runtime/session.py#L165

(same goes for odoo codebase but let's say it's easier to patch)

Would it be acceptable that if the SKIP_PG_USER environment variable is set we skip this test? If yes I'll do a PR now...

I get the following message when I use the generated upgrade_openerp script using openerp 6.0 with this following config:

[buildout]
parts = openerp
versions = versions
find-links = http://download.gna.org/pychart/


[openerp]
recipe = anybox.recipe.openerp[bzr]:server
version = git https://github.com/Odoo/odoo.git odoo 6.0
...

Error:

/home/pverkest/.buildout/eggs/anybox.recipe.openerp-1.9.1-py2.7.egg/anybox/recipe/openerp/runtime/session.py:13: RuntimeWarning: This must be imported with a buildout openerp recipe driven sys.path
  "driven sys.path", RuntimeWarning)
Traceback (most recent call last):
  File "bin/upgrade_openerp", line 40, in <module>
    session = Session('/home/pverkest/openerp/client/odoo_client_buildout/etc/openerp.cfg', '/home/pverkest/openerp/client/odoo_client_buildout')
  File "/home/pverkest/.buildout/eggs/anybox.recipe.openerp-1.9.1-py2.7.egg/anybox/recipe/openerp/runtime/session.py", line 124, in __init__
    config.parse_config(['-c', conffile])
NameError: global name 'config' is not defined

Currently Anybox is migrate to buildbot 9 (public access is not yet available)

I wonder if there is a matter with the setting of our worker(slave) or a real issue. I open an issue to let some analysis:

Test failled on wheezy with:

xcpubslave:~/buildbot.anybox.fr/a_r_odoo-py2_7/build$ bin/pip --version
pip 1.1 from /srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/lib/python2.7/site-packages/pip-1.1-py2.7.egg (python 2.7)

and passed on Jessie with:

jessiepubslave:~/buildbot.anybox.fr/a_r_odoo-py2_7/build$ bin/pip --version
pip 1.5.6 from /srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/local/lib/python2.7/site-packages/pip-1.5.6-py2.7.egg (python 2.7)

log output:

======================================================================
1769ERROR: test_prepare_extracted_buildout_gp_vcsdevelop (anybox.recipe.odoo.tests.test_extract.TestExtraction)
1770----------------------------------------------------------------------
1771Traceback (most recent call last):
1772  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/tests/test_extract.py", line 91, in test_prepare_extracted_buildout_gp_vcsdevelop
1773    self.recipe._prepare_extracted_buildout(conf, self.extract_target_dir)
1774  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/base.py", line 1446, in _prepare_extracted_buildout
1775    for raw, target, sub_dir, abs_path in self._get_gp_vcs_develops():
1776  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/base.py", line 1165, in _get_gp_vcs_develops
1777    target = parse_egg_dir(raw)
1778  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/base.py", line 1161, in parse_egg_dir
1779    return ireq.editable_options['egg']
1780AttributeError: 'InstallRequirement' object has no attribute 'editable_options'
1781-------------------- >> begin captured logging << --------------------
1782anybox.recipe.odoo.base: INFO: Created downloads/ directory
1783anybox.recipe.odoo.base: INFO: Created etc/ directory
1784--------------------- >> end captured logging << ---------------------
1785
1786======================================================================
1787ERROR: test_prepare_extracted_buildout_gp_vcsdevelop_develop_dir (anybox.recipe.odoo.tests.test_extract.TestExtraction)
1788----------------------------------------------------------------------
1789Traceback (most recent call last):
1790  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/tests/test_extract.py", line 115, in test_prepare_extracted_buildout_gp_vcsdevelop_develop_dir
1791    self.recipe._prepare_extracted_buildout(conf, self.extract_target_dir)
1792  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/base.py", line 1446, in _prepare_extracted_buildout
1793    for raw, target, sub_dir, abs_path in self._get_gp_vcs_develops():
1794  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/base.py", line 1165, in _get_gp_vcs_develops
1795    target = parse_egg_dir(raw)
1796  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/base.py", line 1161, in parse_egg_dir
1797    return ireq.editable_options['egg']
1798AttributeError: 'InstallRequirement' object has no attribute 'editable_options'
1799-------------------- >> begin captured logging << --------------------
1800anybox.recipe.odoo.base: INFO: Created downloads/ directory
1801anybox.recipe.odoo.base: INFO: Created etc/ directory
1802--------------------- >> end captured logging << ---------------------
1803
1804======================================================================
1805ERROR: test_prepare_frozen_buildout_gp_vcsdevelop (anybox.recipe.odoo.tests.test_freeze.TestFreeze)
1806----------------------------------------------------------------------
1807Traceback (most recent call last):
1808  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/tests/test_freeze.py", line 145, in test_prepare_frozen_buildout_gp_vcsdevelop
1809    self.recipe._prepare_frozen_buildout(conf)
1810  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/base.py", line 1179, in _prepare_frozen_buildout
1811    for raw, _, _, abs_path in self._get_gp_vcs_develops():
1812  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/base.py", line 1165, in _get_gp_vcs_develops
1813    target = parse_egg_dir(raw)
1814  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/base.py", line 1161, in parse_egg_dir
1815    return ireq.editable_options['egg']
1816AttributeError: 'InstallRequirement' object has no attribute 'editable_options'
1817-------------------- >> begin captured logging << --------------------
1818anybox.recipe.odoo.base: INFO: Created downloads/ directory
1819anybox.recipe.odoo.base: INFO: Created etc/ directory
1820--------------------- >> end captured logging << ---------------------
1821
1822======================================================================
1823ERROR: Test that prepare_frozen_buildout understands existing pinning.
1824----------------------------------------------------------------------
1825Traceback (most recent call last):
1826  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/tests/test_freeze.py", line 164, in test_prepare_frozen_buildout_gp_vcsdevelop_already_fixed
1827    self.recipe._prepare_frozen_buildout(conf)
1828  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/base.py", line 1179, in _prepare_frozen_buildout
1829    for raw, _, _, abs_path in self._get_gp_vcs_develops():
1830  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/base.py", line 1165, in _get_gp_vcs_develops
1831    target = parse_egg_dir(raw)
1832  File "/srv/buildslave/buildbot.anybox.fr/a_r_odoo-py2_7/build/src/anybox/recipe/odoo/base.py", line 1161, in parse_egg_dir
1833    return ireq.editable_options['egg']
1834AttributeError: 'InstallRequirement' object has no attribute 'editable_options'
1835-------------------- >> begin captured logging << --------------------
1836anybox.recipe.odoo.base: INFO: Created downloads/ directory
1837anybox.recipe.odoo.base: INFO: Created etc/ directory
1838--------------------- >> end captured logging << ---------------------
1839
1840----------------------------------------------------------------------
1841Ran 199 tests in 68.713s
1842
1843FAILED (errors=4) 

Fixed in master by PR #26 by @bwrsandman, needs backport in a.r.openerp-1.9

Git 1.7.9 is notably found in Ubuntu 12.04

Sometimes, after a first run of the recipe with merges, the pull/update fails for git with a fatal error:
fatal: Not possible to fast-forward, aborting.. A way to avoid this kind of error is to revert the VCS repositories before the pull/update.

Hi,
First of all thanks a lot for the buildout recipe!

I would like to propose an improvement for the management of upgrade script.
For now the upgrade script is only only one file and can increase quickly in the time. I would prefers to use by default a folder and one script per version.

To be more explicite I want only one upgrade folder with all of my script and this look like something like that :

• upgrade
  • 1.0.0.py
  • 1.1.0.py
  • 1.2.0.py
  • 2.0.0.py

Script should be played in the right order and after each execution of the script the database is commited

I start to do a prototype that look something like that : https://gist.github.com/sebastienbeau/77ca66f2e87cca2c45ad

I would like to know if you are interesteed by including this feature by default in the recipe?

Thanks

With git version 1.7.10.4 (the one shipped with Debian 7), the unit tests don't pass.

From /tmp/tmpexTpCZtest_oerp_recipe_vcs/src/src-repo
 * [new branch]      branch1    -> origin/branch1
 * [new branch]      branch2    -> origin/branch2
fatal: Couldn't find remote ref 84cf26e6c92f26c748c170febfc4beee59499814
fatal: The remote end hung up unexpectedly
> /usr/lib/python2.7/subprocess.py(511)check_call()
-> raise CalledProcessError(retcode, cmd)
(Pdb) pp cmd
['git',
 'pull',
 '--no-edit',
 '/tmp/tmpexTpCZtest_oerp_recipe_vcs/src/src-repo',
 '84cf26e6c92f26c748c170febfc4beee59499814']

I don't think pull on SHA has been added to Git since that version, so it's probably some kind of side effect.

When running the build and something goes wrong, there is very little useful information passed to the user.

I am talking specifically about this line:

Which returns a error such as:

UpdateError: Command '['git', 'pull', '--ff', '--no-commit']' returned non-zero exit status 1

CalledProcessError: Command '['git', 'checkout', '6763a541267dcdddcbe54bf3bdc7f4a3796276bf']' returned non-zero exit status 128

No information as to which repo/branch, which sha, why it returned 1. What was the output message. What the path is.

It would be good to raise the git error message, and provide context as to which repo failed.

As the title said, apply-requirement-file = True (see #45, #43) does not work with most recent version of pip (wich is itself used to read the requirements file).

I do have a fix locally, need to wrap it up properly and find the exact pip version introducing the breaking change (and if or why integration tests didn't warn about it)

When running the upgrade scripts there is a warning about the cursor not being closed explicitely

WARNING ? openerp.sql_db: Cursor not closed explicitly

I can close the cursor myself in every upgrade.py script, however I return from the script in several places (upgrade, install, error, etc). It seems like the function calling upgrade.run() should be the one closing the cursor.

If the working set has a distribution installed as a wheel, it'll be mistaken for a "developed" distribution
(that's the older terminology for "editable"). Actually, all versions of pkg_resources I've tried (including 26) give them the DEVELOP_DIST precedence. It's not clear to me whether its intentional from the setuptools side, but correctly identifiying distributions that are from the develop buildout options (or extension) is really important in the freeze/extract processes.

I don't expect this to be a problem right now : as far as I know, zc.buildout largely ignores wheels for now, and we've consistently advised everybody to run in a totally clean virtualenv, meaning all that's installed has been installed by zc.buildout. Bottom-line: the upcoming 1.9.2 release can proceed without solving this.
Still, it's a small timebomb that should be on the todo-list.

See while trying to understand the tests problems with Babel solved by #82, cause actually I had Babel as a wheel.

result by coveralls.io: 40%
result in the build output: 86%

The anybox recipe 1.9 still has a dependencie on PyChart in the server.py
As gna.org is down and no mirror for it has popped up, this will break the install.

I can't find any mention of pychart in the requirement in v8.0 so I think it can be removed (as is done in later versions)

Not sure if this is an issue or merely a question.

When using the python_odoo script generated by the recipe, it seems it connects to all available databases. This seems to be the normal Odoo behaviour, but unncessarily uses up postgres connections.

However, when using a script, we connect using session.open(db=DATABASE_NAME) and typically want to work on one database only.

Is there an easy way to make sure the script connects to only one database?

anybox.recipe.openerp introduced a uniform parser for multiline options.
It causes a regression in gunicorn.preload_database in the most common case where there is just one database. The error appears upon execution:

OperationalError: FATAL: la base de données « o » n'existe pas

(here o is the first letter of the database name)

If there are truly several databases, then the recipe fails

There is an entry in ir.config_parameter of the form:

 Key    database.create_date
 Value  2015-03-10 14:20:55 

It would be useful to know when the last upgrade ran

 Key    database.upgrade_date
 Value  2015-03-20 10:10:43 

The builder is red on version 6.1 since the end of January.

Odoo change the way to get the last built for version older than 7.0:
before: http://nightly.odoo.com/6.1/nightly/src/openerp-6.1-latest.tar.gz
now: http://nightly.odoo.com/old/openerp-6.1/6.1.20140804/openerp-6.1-20140804-233536.tar.gz

@veloutin showed me this awesome patch he makes to python_odoo to use an ipython console to take advantage of its features.

Could this be officially added to the recipe?

--- bin/python_odoo 2014-07-25 15:11:16.467096106 -0400
+++ bin/python_odoo 2014-07-25 15:11:05.073762648 -0400
@@ -66,4 +66,9 @@

 if _interactive:
     del _interactive
+    try:
+        import IPython
+    except ImportError:
+        __import__("code").interact(banner="", local=globals())
+    else:
+        IPython.start_ipython(user_ns=globals())
-    __import__("code").interact(banner="", local=globals())

This is more than a question than an issue.

Is there a way to run Odoo from this recipe with gevent longpolling support? I have tried starting both the start_odoo and gevent_odoo scripts with workers = 0 in my cfg file but the longpolling calls 404. When i run only start_odoo with workers = 4, longpolling works but the application is much less responsive.....

Thanks!

Commits aren't persistent in Git, and that has been a major topic in the recent refactor of the Git support for the recipe.

For better efficiency, the freeze option should stop using shas in its output. Instead, it should introspect HEAD for tags it could have and use what it's found. Ideally it should not even accept to freeze if no tag is available, but that would be too disruptive for users' current workflows (odoo produces almost no tags)
It could also produce a tag of its own, but that would be useful only for those that manage their own forks. One can imagine lots of options to control that behaviour (tag only if needed, always tag, tag naming policy etc.)

The open question would be which tag to use if the HEAD has several of them. Maybe we can add an option to control that (with a regexp, a prefix) ?

Do you need any help before doing a new release? The Last one is from 2014-12-17 which still doesn't have session.env for easily accessing the new API.

The recipe always assumes that sources of libraries declared by vcs-extends-develop are located at the root of the buildout. This assumption is true only if the develop-dir option is not used.

The buildout recipes redownload a copy of Odoo for each new instance.

Is it possible to just specify an already-downloaded, shared, local folder as the Odoo instance instead?

When starting a new session there is a nice message to let user know how he can start to work with

$ bin/python_odoo 
To start the OpenERP working session, just do:
    session.open(db=DATABASE_NAME)
or, to use the database from the buildout part config:
    session.open()
All other options from buildout part config do apply.
Then you can issue commands such as
        session.registry('res.users').browse(session.cr, 1, 1)

It could be nice to wrap new API and display a message on V8 and higher. I suggest:

$ bin/python_odoo 
To start the OpenERP working session, just do:
    session.open(db=DATABASE_NAME)
or, to use the database from the buildout part config:
    session.open()
All other options from buildout part config do apply.
Then you can issue commands such as
        session.registry('res.users').browse(session.cr, 1, 1)
or for v8 and higher
        session.env['res.users'].browse(1)

Actually we have to do that:

>>> session.open(db='my_db_name')
>>> ...
>>> import openerp;
>>> env = openerp.api.Environment(session.cr, session.uid, {})
>>> env['res.users'].browse(1)

I'm fillng the bug to let people now that this is under investigation and shouldn't be a problem for long.
Today's changes in the 8.0 branch made the recipe incompatible with the configmanager from tools/config.py

See this build for example:
http://buildbot.anybox.fr/builders/odoo-80-postgresql-9.3/builds/495

And this commit: odoo/odoo@f04f409

Hi folks,
I have a buildout for odoo 7.0, and when i use the latest recipe (at moment 1.9.1), it fails:

Getting distribution for 'PIL'. anybox.recipe.odoo.base: Could not find or install 'PIL'. You don't need to require it for OpenERP any more, since the recipe automatically adds a dependency to Pillow. If you really need it for other reasons, installing it system-wide is a good option. Original exception zc.buildout.easy_install.MissingDistribution says: Couldn't find a distribution for 'PIL'. While: Installing openerp. Error: Couldn't find a distribution for 'PIL'.

As you can see, in branch 7.0 [0] PIL is a requirement, not as in branch 8.0 [1] when the requirement is Pillow

Any suggestions are appreciated.
Thank you.

[0] https://github.com/odoo/odoo/blob/7.0/setup.py#L129
[1] https://github.com/odoo/odoo/blob/8.0/setup.py#L142