gristlabs_grist-core/sandbox/pyodide/README.md

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.
add a pyodide-based "sandbox" flavor (#437) This adds a new `GRIST_SANDBOX_FLAVOR=pyodide` option where the version of Python used for the data engine is wasm, and so can be run by node like the rest of the back end. It still runs as a separate process. There are a few small version changes made to packages to avoid various awkwardnesses present in the current versions. All existing tests pass. This is very experimental. To use, you'll need something with a bash shell and make. First do: ``` cd sandbox/pyodide make setup # README.md and Makefile have details cd .. ``` Then running Grist as: ``` GRIST_SANDBOX_FLAVOR=pyodide yarn start ``` should work. Adding a formula with content: ``` import sys; return sys.version ``` should return a different Python version than other sandboxes. The motivation for this work is to have a form of sandboxing that will work on Windows for Grist Electron (for Linux we have gvisor/runsc, for Mac we have sandbox-exec, but I haven't found anything comparable for Windows). It also brings a back-end-free version of Grist a bit closer, for use-cases where that would make sense - such as serving a report (in the form of a Grist document) on a static site. 2023-03-06 21:56:25 +00: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.