[odoo] startup script for openerp-gevent

[Georges Racinet]

Odoo has a new script for aynchronous long polling, called openerp-gevent.
The recipe needs to produce the analogous one for its context.

The openerp-gevent script is automatically called from server.py if the --workers option is passed.

The recipe must find a way to have it launch its own generated script instead.

Repeating what I wrote earlier on https://bugs.launchpad.net/bugs/1317269 about gevent-openerp :

* it has an hardcoded shebang on /usr/bin/env python
* it can't have the sys.path initialization that is the core principle of zc.buildout.

Basically, that openerp-gevent should have been the one generated by
setup.py (it looks very much alike) and should not be versioned with the sources. Besides, the
launcher should not make any assumptions on its name or path. I'll try
and explain that to the odoo team.

In the meanwhile, a monkey patch from bin/start_openerp should do the trick

[Georges Racinet (gracinet)]

Done ! The gevent server seems to start smoothly, and I could also change its port from buildout.cfg
This proves that the config is forwarded properly (saw the addons paths be correct, too).

Besides that, I did not perform functional tests, hence can't really tell if it works as expected.

On a funny note, this benefits from efforts done last summer to support OpenERP 5.0 in that there was already a known-to-work way to monkey patch during startup.

I think these changes can go to the stable branch as well, since (again) everything is protected by major version checks, and would appreciate user feedback

[Georges Racinet (gracinet)]

Correcting a small imprecision on my part.

Actually the hardcoded she-bang is expected by distutils in order to replace it by the correct python. Therefore it does not harm virtualenv / pip users.

Reference: https://docs.python.org/2/distutils/setupscript.html#installing-scripts

I'd prefer something like #! python will be replaced at setup time to avoid confusion but that's true nitpicking and really debatable :-)