gristlabs_grist-core/sandbox/pyodide
Paul Fitzpatrick a18007ae7a
remove cached packages for pyodide when cleaning up (#650)
If these get messed up, it is hard to track down the problem.
2023-08-29 15:21:34 -04:00
..
build_packages.sh add a version number to precompiled pyodide resources (#607) 2023-08-02 16:29:43 -04:00
Makefile remove cached packages for pyodide when cleaning up (#650) 2023-08-29 15:21:34 -04:00
package_filenames.json update pyodide package list (#648) 2023-08-29 08:52:38 -04:00
packages.js Upgrade to Pyodide 0.23.4 (with Python 3.11) and compile dependencies (#603) 2023-08-02 20:15:53 +02:00
pipe.js add a pyodide-based "sandbox" flavor (#437) 2023-03-06 16:56:25 -05:00
README.md add a pyodide-based "sandbox" flavor (#437) 2023-03-06 16:56:25 -05:00
setup.sh Upgrade to Pyodide 0.23.4 (with Python 3.11) and compile dependencies (#603) 2023-08-02 20:15:53 +02:00

This is a collection of scripts for running a pyodide-based "sandbox" for Grist.

I put "sandbox" in quotes since pyodide isn't built with sandboxing in mind. It was written to run in a browser, where the browser does sandboxing. I don't know how much of node's API ends up being exposed to the "sandbox" - in previous versions of pyodide it seems the answer is "a lot". See the back-and-forth between dalcde and hoodmane in: https://github.com/pyodide/pyodide/issues/960 See specifically: https://github.com/pyodide/pyodide/issues/960#issuecomment-752305257 I looked at hiwire and its treatment of js globals has changed a lot. On the surface it looks like there is good control of what is exposed, but there may be other routes.

Still, some wasm-based solution is likely to be helpful, whether from pyodide or elsewhere, and this is good practice for that.


To run, we need specific versions of the Python packages that Grist uses to be prepared. It should suffice to do:

make setup

In this directory. See the Makefile for other options.