erp5_data_notebook: environment object implementation and refactoring to ERP5 kernel
@Tyagov review, please. I'm creating a test suite now and will post about the test results as soon as they are available.
-
An environment object was implemented to help us deal with the multiprocess architecture of ERP5 and objects that cannot be easily stored in the ZODB. It stores definition of functions, classes and variables as string. The implementation uses a dumb Environment class to allow users to make
defineandundefinecalls, which are captured and processed by an AST transformer before code execution. -
Along with the environment object, an automatic "import fixer" was created. It does not allow users to import modules as they normally would, because this may cause collateral effects on other users' code. A good example is the plot settings in the matplotlib module. It will fix normal imports, make them use the environment object mentione earlier automatically and warn the user about it.
Some bugs were fixed with this new implementation:
-
https://nexedi.erp5.net/bug_module/20160318-7098DD, which reports an inconsistency on portal catalog queries between Jupyter and Python (Script) objects. Probably an issue with user context storage in ActiveProcess
-
https://nexedi.erp5.net/bug_module/20160330-13AA193, which reports an error related to acquisition when trying to plot images, which happened in other situations, although this is not officially reported in Nexedi's ERP5. This probably also was happening because of old user context storage.