Support pyodide as a kernel backend

[patrickmineault]

Description / Summary

It would be nice if it were possible to use pyodide as a backend to run jupyterbooks in addition to binder.

Value / benefit

This is a bit of longer term roadmap item, but I think pyodide would make a lot of sense as a backend for some use cases. Some advantages of pyodide:

• Works offline. For use cases where a jupyterbook is delivered through an Electron app or Kolibri, pyodide can work offline.
• No kernel rebuild overhead, faster development. Changing the underlying repo does not trigger rebuilds on the binder side.
• Doesn't use binder resources. For books used as educational resources for large classes, the binder backend may cause hundreds of simultaneous kernels to be spawned. Local pyodide resources would not have this issue.
• Doesn't expire. Remote binder kernels expire after 10 minutes. Local kernels don't.
• Reasonably fast. In my tests, loading up a "hot" binder instance takes about the same time as loading pyodide with numpy support (O(10 seconds)).

Implementation details

There's some minor surgery to be done in initThebe, namely to init the pyodide runner rather than the remote runner. There are some changes to the UI, namely "restarting the kernel" doesn't make as much sense. Most of the work to be done is in the renderCell callbacks. We could rip out the binder logic and put it into a separate class and create a second class with the same interface for pyodide.

There's some work to be done on the configuration side of things, namely to specify packages to be loaded, and associated documentation.

There's an attempt at implementing this here as well! #465 (comment)

Tasks to complete

No response

[welcome]

Thanks for opening your first issue here! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out EBP's Code of Conduct. Also, please try to follow the issue template as it helps other community members to contribute more effectively.

If your issue is a feature request, others may react to it, to raise its prominence (see Feature Voting).

Welcome to the EBP community! 🎉

[choldgraf]

I think that this would be super cool as well. My main concern is that this would significantly change the scope and complexity of this package. Do you have an intuition for how much extra work / complexity this would take?

[patrickmineault]

Here's a slightly broken demo of pyodide support inside of thebe:

https://612b174edb24b0b42d075e94--tender-kowalevski-137345.netlify.app/development/local.html

Source: https://github.com/patrickmineault/thebe/tree/pyodide

As you can see, there's very little surgery to be done on thebelab.js - all the work is done in two extra pyodide js files. One is for the kernel manager, the other for the worker which acts as the kernel. To reuse KernelFutureHandler from jupyterlab as much as possible, the worker should send the same kinds of messages that a normal jupyter kernel would. This version is incomplete, but jupyterlite has a pretty complete implementation here AFAICT:

https://github.com/jupyterlite/jupyterlite/blob/aa7fd0778fe722e72a002456494d6e27091d21d8/packages/pyolite-kernel/src/worker.ts

As for the kernel manager, it mimics the KernelManager, KernelConnection, etc. classes from jupyterlab. I can't find an exact match in jupyterlite, but I haven't done a thorough investigation.

In brief, I think that implementing a worker wouldn't be that hard given prior art from jupyterlite. Implementing the kernel manager is a bigger chunk of work for someone not familiar with jupyterlab internals.

[nthiery]

cc: @SylvainCorlay, as the QuantStack / JupyterLite team might have suggestions / interest.

[SylvainCorlay]

Hey everyone, Thanks for the heads up Nicolas. Yeah I think it would be interesting to leverage the jupyterlite kernel infrastructure to enable many frontend kernels. We already have python (based on pyodide), p5, javascript, lua, and more coming (all xeus kernels ideally). Ideally any jupyterlite front end kernel should work with thebe... For the Python case, benefits of using the existing pyolite are widgets support, Ipython magics, etc. Ping @jtpio.

…

On Sun, Aug 29, 2021, 07:49 Nicolas M. Thiéry ***@***.***> wrote: cc: @SylvainCorlay <https://github.com/SylvainCorlay>, as the QuantStack / JupyterLite team might have suggestions / interest. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#465 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASJOFWHOTLC7BUJZBH3FNDT7HDABANCNFSM5C7IGQCQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[choldgraf]

It would be fantastic if folks with familiarity in the JupyterLite world could advise on the best way to implement this, and how much work it would likely be.

Another question we should figure out is what kind of configuration to expose to people. See the thebe configuration for reference:

https://thebe.readthedocs.io/en/latest/config_reference.html

Right now we use binderOptions to configure Binder instances. Maybe we introduce a pyodideOptions configuration? Or if it's unlikely there will be a lot of configuration needed, perhaps we could just re-use kernelOptions have a special key for pyodide kernels or something?

[moorepants]

Note that there is a jupyterlite #412 issue also.

[jtpio]

One is for the kernel manager, the other for the worker which acts as the kernel. To reuse KernelFutureHandler from jupyterlab as much as possible, the worker should send the same kinds of messages that a normal jupyter kernel would. This version is incomplete, but jupyterlite has a pretty complete implementation here AFAICT

JupyterLite implements a JupyterLab "server" (Jupyter Server + a couple of extra endpoints) that runs in the browser, which includes a kernel manager. The Pyodide-based kernel (currently named Pyolite) implements most of the Jupyter Protocol so it would indeed be very interesting to see how to reuse this stack!

There is an overview architecture diagram in the documentation: https://jupyterlite.readthedocs.io/en/latest/architecture.html

The lab and retro frontends are left untouched, and the in-browser server connection is done by providing a different ServerConnection.ISettings. So in the case of thebe, maybe it will just be a matter of:

• running the JupyterLite server in the browser (the right part of the diagram above)
• providing the ServerConnection.ISettings to connect to it (like in jupyterlite) here: https://github.com/jupyterlite/jupyterlite/blob/66ccfd172419acb56d479fd3f3353e0d5d1f2dcd/packages/server/src/service.ts#L20-L24
• pass the server settings in thebe here:

https://github.com/executablebooks/thebe/blob/efa85cde13489b5ae028040be36e1fbad431152c/src/kernels.js#L42-L44

[stevejpurves]

@jtpio Thanks for the guidance!

I made an attempt at this and made some progress and wonder if you could take a look at this and advise on direction / where I am going wrong.

My PR with those changes is here: stevejpurves#40

The code to bring up the JuptyerLiteServer I think is Ok, in general maybe but I definitely feel like missing something in terms of the kernel initialization. If you see the two comments on that PR, I hit (and have declared globals as an attempted workaround) issues when loading wheels from local relative URLs. I wonder if I am missing something about how to include pyolite properly, e.g. does it need to be dynamically loaded.

@jtpio Any further hints/direction that you could give would be appreciated.

(PS @choldgraf my aim is to get an initial rough implementation working to further discussion)

[jtpio]

Nice, thanks @stevejpurves for starting this it looks promising!

[stevejpurves]

ongoing work for this is here: executablebooks/thebe-core#3

[saulshanabrook]

Now that the above linked PR is merged, does anyone know the next steps to get a client-side version of execution working in Jupyter Book?

[rowanc1]

@saulshanabrook the new work to integrate thebe-core is ongoing on this pr:

• Integrate thebe-core #554
  There is still a large checklist going on in there to integrate back into thebe features.

[stevejpurves]

#620 now has 2 out of 3 demos showing that this is now possible and easy enough to deploy

[jobovy]

That's wonderful! It took me some digging around to find that these demos are rendered at

https://executablebooks.github.io/thebe/

Is that linked to anywhere or is it not a stable URL yet (maybe this will be incorporated into the regular thebe docs soon?)

[rowanc1]

Working with @stevejpurves over the next week to do a full revamp on the docs for thebe and mystjs just in time for a jupyter-con talk!! 🚀

Super excited about these updates. :)

[stevejpurves]

@jobovy just added a [launch|thebe] badge to the README but yeah needs to be more prominent -- as @rowanc1 mentioned going to be a big uhs on updated docs next week

also need to get the JupyterBook setup tested and documented as part of that cc @saulshanabrook

[nthiery]

Looking forward your presentation at JupyterCon! And deploying the solution
on my sites :-)