python_odoo with ipython about anybox.recipe.odoo HOT 14 CLOSED

@sandreanybox had something similar a while ago, but IIRC there were problems with added dependencies (IPython requiring sqlite or something similar, stuff breaking not at init maybe ?), and I ended up not including it. But it was of wider application (not only in interactive sessions) and also involved iPdb

Simon, anything more precise about this ?

I'm all willing to reconsider especially since this patch would apply for the interactive mode only.
And while I usually like to keep it low on the UI helpers, I agree that the typical code one'd like to write in such sessions would benefit quite a lot.

from anybox.recipe.odoo.

This is not ipdb, but IPython.
It's very beneficial to have ipython in python_odoo since our dev process can be prototyped in these interactive session.
They're also a very user-friendly way of examining an Odoo database.

Related issue:
In interactive mode using ipython, the following message appears (7.0)

2014-12-12 18:48:48,746 15687 WARNING db_name openerp.osv.orm.browse_record.res.users: Field '_ipython_display_' does not exist in object 'browse_record(res.users, 1)'

And tab completing on a browse object (7.0):

2014-12-12 18:49:55,508 15687 WARNING db_name openerp.osv.orm.browse_record.res.users: Field '__members__' does not exist in object 'browse_record(res.users, 1)'
2014-12-12 18:49:55,509 15687 WARNING db_name openerp.osv.orm.browse_record.res.users: Field '__methods__' does not exist in object 'browse_record(res.users, 1)'
2014-12-12 18:49:55,509 15687 WARNING db_name openerp.osv.orm.browse_record.res.users: Field 'trait_names' does not exist in object 'browse_record(res.users, 1)'
2014-12-12 18:49:55,510 15687 WARNING db_name openerp.osv.orm.browse_record.res.users: Field '_getAttributeNames' does not exist in object 'browse_record(res.users, 1)'

from anybox.recipe.odoo.

I am using this patch and it is actually awesome.
👍

from anybox.recipe.odoo.

@gracinet Note that even though this requires IPython to work, it falls back to the current behavior if it is not available. So this doesn't actually add any hard dependency.

from anybox.recipe.odoo.

@veloutin yes I'd noticed that. Nice to meet you, btw.
Care to make a direct pull request on the a.r.openerp-1.9 branch ? This way GitHub will take note, and I'll remerge to master afterwards (I prefer it that way).

But I'm done for today anyway (CET time, here)

from anybox.recipe.odoo.

@gracinet This involves changing the global py_script_template in rc.buildout.easy_install.

This does not seem like a very safe thing to do from the recipe. I can't see any way of changing it another way either.

I proposed a patch to buildout a while ago with no result: buildout/buildout#189

from anybox.recipe.odoo.

@bwrsandman Ah yes, I wasn't thinking ! The recipe itself has a notion of a "soft depency which probably could be used to know before hand if IPython is usable, and then the initialization string could be used, but that's a bit convoluted

from anybox.recipe.odoo.

Hi folks.

No need to patch anything.

If you just add ipython to the eggs and openerp_scripts settings of your anybox.recipe.odoo buildout part you'll get an ipython_odoo intepreter in the same context as python_odoo right now.

See example here:
https://gist.github.com/leorochael/888f1a728b227676244c

from anybox.recipe.odoo.

@leorochael Thank you for the tip. What do you think to make a PR to puts this information in the doc.

from anybox.recipe.odoo.

That's cool. However, as far as this project is concerned, ipython is incomplete as the openerp session is not opened.

$ bin/python_odoo -c "print(session)"
<anybox.recipe.odoo.runtime.session.Session object at 0x7f13b6b893d0>
$ bin/ipython_odoo -c "print(session)"
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-1-006ec0a38b54> in <module>()
----> 1 print(session)

NameError: name 'session' is not defined

--- bin/python_odoo 2015-07-23 11:03:25.435314664 -0400
+++ bin/ipython_odoo    2015-07-23 11:03:25.461981476 -0400
@@ -1,7 +1,6 @@
 #!/tmp/env/bin/python2

 import sys
-
 sys.path[0:0] = [
   '/tmp/eggs/nose-1.3.7-py2.7.egg',
   '/tmp/eggs/ipython-3.2.1-py2.7.egg',
@@ -68,38 +67,8 @@

 from anybox.recipe.odoo.runtime.session import Session
 session = Session('/tmp/etc/odoo.cfg', '/tmp')
-if len(sys.argv) <= 1:
-    print('To start the OpenERP working session, just do:')
-    print('    session.open(db=DATABASE_NAME)')
-    print('or, to use the database from the buildout part config:')
-    print('    session.open()')
-    print('All other options from buildout part config do apply.')
-    print('Then you can issue commands such as')
-    print("        session.registry('res.users').browse(session.cr, 1, 1)")
-
-
-_interactive = True
-if len(sys.argv) > 1:
-    _options, _args = __import__("getopt").getopt(sys.argv[1:], 'ic:m:')
-    _interactive = False
-    for (_opt, _val) in _options:
-        if _opt == '-i':
-            _interactive = True
-        elif _opt == '-c':
-            exec(_val)
-        elif _opt == '-m':
-            sys.argv[1:] = _args
-            _args = []
-            __import__("runpy").run_module(
-                 _val, {}, "__main__", alter_sys=True)

-    if _args:
-        sys.argv[:] = _args
-        __file__ = _args[0]
-        del _options, _args
-        with open(__file__, 'U') as __file__f:
-            exec(compile(__file__f.read(), __file__, "exec"))
+import IPython

-if _interactive:
-    del _interactive
-    __import__("code").interact(banner="", local=globals())
+if __name__ == '__main__':
+    sys.exit(IPython.start_ipython())

The last line IPython.start_ipython() needs fixing. Firstly, the globals aren't passed. IPython.start_ipython(user_ns=globals()) would be what we need. Second, the python version hides the banner. IPython.start_ipython(display_banner=False) would fix that. Third, the message (or banner) about using session is missing.

So, the last two lines of ipython_odoo should be:

if __name__ == '__main__':
    sys.exit(IPython.start_ipython(user_ns=globals(), display_banner=False))

from anybox.recipe.odoo.

@bwrsandman, I've updated the gist with information on how to pass session into the IPython namespace (and did the same for for bpython) by using the arguments option of openerp_scripts.

Passing the whole globals(), or omitting or changing the banner could similarly be done by manipulating arguments as well.

from anybox.recipe.odoo.

Nice. command-line-options=-d is not necessary.

Can I ask why, you added the egg ipython[notebook] before. When try bin/ipython_odoo notebook, I get.

$ bin/ipython_odoo notebook
TypeError('find_module() takes exactly 3 arguments (2 given)',)
> /usr/lib64/python2.7/pkgutil.py(475)find_loader()
    474     for importer in iter_importers(fullname):
--> 475         loader = importer.find_module(fullname)
    476         if loader is not None:

from anybox.recipe.odoo.

True -d is not necessary, I just thought it was a good example of showing how the options for odoo_scripts can apply to interactive interpreters as well.

I hand't actually tried the IPython notebook but I was going to. I removed it from the gist because:

• it's not necessary for the purposes of this discussion
• it pulls in even more dependencies, some of which require more system packages (libzmq-dev, for instance)
• it'll likely require extra code to work

Regarding the last point: buildout (actually zc.recipe.egg:scripts) generates scritpts in bin/ that manually insert a lot of paths (mostly eggs) in sys.path, because buildout does not install them on the Python library path by design.

However, these inserted paths are not propagated to subprocesses by default, since they aren't in os.env['PYTHONPATH'] either.

Now IPython notebook launches kernels as subprocesses, so they're not going to see the extra paths.

So, even though I haven't tried yet, I believe the only way of getting IPython notebook to run in an "odoo server" context is to import and instantiate an a.r.o.runtime.session.Session object manually inside the notebook, since it's in a different process than the generated script).

And that will only be possible if the generated script somehow export its own sys.path into the PYTHONPATH environment before launching kernels.

And all this seems still to be unrelated to the error you got.

from anybox.recipe.odoo.

@leorochael,

Thanks for the gist!

As @lmignon 👍 to add it in the documentation!

from anybox.recipe.odoo.