Make OpenCOR's simulation environment available in a Python package

[dbrnz]

Currently OpenCOR provides the user with a Python console via an embedded Python interpreter. This also allows OpenCOR to run as a Jupyter kernel and have clients (Web browsers, IPython consoles, etc) run Python code contained in Jupyter Notebook files.

The current implementation though does not allow a user with a generic Python installation to take advantage of OpenCOR. To do so would require having OpenCOR available as a library with Python wrappers. This will necessitate a rework of some of OpenCOR and its current Python implementation.

Because OpenCOR makes extensive use of Qt, and because any generic opencor package should be able to coexist with other Qt5 Python packages, we need to choose a suitable Qt5 package as a base (PySide2 has a better license than PyQt5) and use its Qt binaries in our library version of OpenCOR. OpenCOR's third-party libraries will also have to be bundled with our Python package.

[agarny]

Personally, to make OpenCOR's simulation environment (and maybe other aspects of OpenCOR too, at some point? E.g. the conversion of a CellML file to say Python) available in a Python package would be very nice to have since this would allow people to use OpenCOR directly from their Python environment.

However, this seems to have quite a few technological implications, so we will have to think very carefully about it and, in fact, make sure that this is the kind of Python support that Python users would expect to have for OpenCOR (@hsauro, @hsorby, @metatoaster, @MichaelClerx, @nickerso, @ssafaei, any views on this?).

The current implementation though does not allow a user with a generic Python installation to take advantage of OpenCOR. To do so would require having OpenCOR available as a library with Python wrappers. This will necessitate a rework of some of OpenCOR and its current Python implementation.

If we were to go that route, does it mean that our current Python support approach would be dropped in favour of this new one, or could it live alongside the new approach?

Because OpenCOR makes extensive use of Qt, and because any generic opencor package should be able to coexist with other Qt5 Python packages, we need to choose a suitable Qt5 package as a base (PySide2 has a better license than PyQt5) and use its Qt binaries in our library version of OpenCOR. OpenCOR's third-party libraries will also have to be bundled with our Python package.

Regarding PySide 2 vs. PyQt5, the former has become the official Qt for Python, so that would settle it for me. However, quite a few bindings seem to be missing from PySide 2 (see here)?

[MichaelClerx]

When using it from Python, would the Qt parts be necessary? It'd simplify things a lot if they weren't (i.e. just using the simulation / cellml parts, not the GUI)

[agarny]

When using it from Python, would the Qt parts be necessary? It'd simplify things a lot if they weren't (i.e. just using the simulation / cellml parts, not the GUI)

Right now, we can already run a simulation from Python without the GUI side of OpenCOR, if that's what you mean.

[MichaelClerx]

So where do the python bindings for Qt come in? Don't really see why they'd be needed!

[agarny]

@dbrnz may have to explain things further, but as far as I understand it, right now, we ship our own copy of Python with OpenCOR, as well numpy, scipy, etc. so people can do some basic things with simulation results. People can install additional Python packages if they want, but this means that whenever a newer version of OpenCOR gets installed, they need to reinstall their additional Python packages. Also, I get the impression (@dbrnz to correct me here, if needed) that Python support in OpenCOR is currently done through Jupyter notebooks.

Personally, I wish we could use OpenCOR directly from a Python script using a generic Python installation (as well as have a Python console in the GUI version of OpenCOR, which we already do), and this is what this issue is about. However, I want to make sure that this is indeed what Python users would expect to have when it comes to Python support in OpenCOR (since this is going to involve quite a bit of work).

[dbrnz]

@dbrnz may have to explain things further, but as far as I understand it, right now, we ship our own copy of Python with OpenCOR, as well numpy, scipy, etc. so people can do some basic things with simulation results.

Of the packages shipped, numpy is required because OpenCOR's data arrays are wrapped as NumPy arrays; ipython and its dependencies provide the IPython console window; jupyter and its dependencies allow running as a Jupyter server (a lot of these packages are also part of IPython); scipy and matplotlib are bundled as a convenience for users.

People can install additional Python packages if they want, but this means that whenever a newer version of OpenCOR gets installed, they need to reinstall their additional Python packages.

That's true for any major Python upgrade unless the user sets up local directories to hold installed packages, separate from their Python installation. The same can be done for OpenCOR's Python -- it's just not an out-of-the-box thing for Python novices. Hmm, we could do this automatically by using say /Documents/OpenCOR/Python/Packages as the location of user installed packages.

Also, I get the impression (@dbrnz to correct me here, if needed) that Python support in OpenCOR is currently done through Jupyter notebooks.

No. Python code is run by libpython with OpenCOR supplying a Python module to access simulations and their data. OpenCOR's Python can also run Jupyter kernel code (the JupyterKernel plugin) and so execute Python code in Notebooks.

PythonQt is used to embed Python into OpenCOR's C++ Qt code. This is the approach taken by other Qt-based applications that provide Python scripting, including Slicer and MeVisLab.

So where do the python bindings for Qt come in? Don't really see why they'd be needed!

@MichaelClerx, the non-gui code in OpenCOR makes extensive use of Qt classes (e.g. for strings, lists, plugins, signals/slots, etc, etc), so any Python wrapper for an OpenCOR library must also wrap QObjects. The alternative would be to provide the non-Gui functionality of OpenCOR in a library that doesn't use Qt.