Hi,

Just found this repository and it looks great! Inspired by your PRs to numpy and sympy to use this REPL to allow people to try out code in documentation pages, I was interested in using this for some of my code. However, for packages that aren't part of pyodide directly, users would have to first do something like

import micropip
await micropip.install('PACKAGE')

before they can import PACKAGE. That would be confusing for users who don't know pyodide. My understanding is that pyodide does not want to include Python packages that have pure Python wheels available on PyPI, so this would be an issue for many packages.

This quick PR allows for an install URL parameter that lists a set of packages to quietly install with micropip (I wasn't sure whether I should use micropip or piplite, but both work). It works both with lists of packages (&install=kimmy,scipy) or with wheel URLS (&install=https://astro.utoronto.ca/~bovy/galpywheels/galpy-1.8.0.dev0-py3-none-any.whl&code=import%20galpy) .

I don't have any prior experience with TypeScript or the Jupyter backend, so there might be better ways to do this, but injecting the code and removing the cell seems to do what I want (I couldn't figure out how to just have the kernel execute a bit of code...).

This works locally, but I could push a version somewhere to illustrate use better if necessary (and can add to CHANGELOG and what not if you're inclined to accept this PR).

Thanks!

Edit: Full example using my galaxy chemical evolution code kimmy on the Vercel deployment here.

Fixes #8

• [x] Add toolbar buttons
• [x] Control toolbar visibility via a query string parameter (opt-in)

https://user-images.githubusercontent.com/591645/152146676-dc93489a-11f4-4cc9-88e0-e2075ae5c331.mp4

Opt-in toolbar

https://user-images.githubusercontent.com/591645/152147186-f23be261-14c3-4553-b2e3-37db60e675c2.mp4

Fixes #2 Fixes #1

So it's easier to customize the app than patching the CSS.

Populate code via query string parameters

https://user-images.githubusercontent.com/591645/152044572-af203c12-9328-4e48-8ed9-11de2e8f82ec.mp4

Problem

The URL api is robust for one-off solutions, but makes it harder to integrate.

Proposed Solution

In addition to a well-documented URL param scheme, offer a postMessage API that allows for basic things like "run some code", arbitrary lumino commands, or anything that an extender can imagine.

Background

Having fought with more than a few IFrames, it can be nice to offer both a bare-minimum, fire-and-mostly-forget URL api, as well as a well-structured, message-based API. A good (counter-)example is the drawio embed mode:

• hooray! it can do lots of things!
• boo! that's pretty much it for docs!
  • a robust API in a JSON schema and typings would go a long way to helping implementers who wanted to build e.g. replite-react or replite-vue or whatever they want
    • indeed, as a low-effort integrator demo, it could use rjsf to draw a message builder/viewer

Why both?

By splitting "long term" URL params and "on-demand" postMessage an integrator can then get interesting interplay effects: pass ?ui=0&input=0 and then have the host take over firing all of the execute methods with their own buttons

For e.g. wasm-based kernels, until we can figure out a SharedWorker worker kernels it's particularly important to not add 10s of 100mb kernels, even if in iframes. In a long-form document, a more feasible approach one would be to have a single iframe/kernel/cell, fixed in the viewport, that gets updated as the reader scrolls/clicks on things.

Design Considerations

As for what actually goes in this API: a really quick win is the app.commands.execute... while no a-priori schema exists, a running lab could at least enumerate what commands it has.

The repl app is now part of the main JupyterLite distribution: https://jupyterlite.readthedocs.io/en/latest/applications/repl.html

Added in https://github.com/jupyterlite/jupyterlite/pull/498

This PR updates to using the upstream app:

• [x] Update to jupyterlite>=0.1.0a24
• [x] Strip source maps (pending upstream release)
• [x] Ship only the repl app (pending upstream release)

Eventually this minimal REPL should be one of the apps distributed by default in JupyterLite.

For now lite ships lab and retro by default: https://jupyterlite.readthedocs.io/en/latest/api/py/jupyterlite.html#jupyterlite.constants.JUPYTERLITE_APPS

There could be a new app called cell.

If this is a standalone app like retro, the look and UX could be different and not limited to the JupyterLab code console.

We'll want to fix https://github.com/jupyterlite/jupyterlite/issues/118 first though.

The cell app could be either in core, or as a third-party app under the jupyterlite org. The latter might require some work in the jupyterlite CLI to allow apps as (federated) plugins.

Related to https://github.com/jupyterlite/jupyterlite/issues/148

Automated Changelog Entry for 0.1.1 on main

After merging this PR run the "Full Release" Workflow on your fork of jupyter_releaser with the following inputs | Input | Value | | ------------- | ------------- | | Target | jtpio/replite | | Branch | main | | Version Spec | 0.1.1 | | Since | first-commit |

Widgets are not supported in code consoles yet (https://github.com/jupyter-widgets/ipywidgets/pull/3004).

This should help fix the following errors logged in the dev tools console:

As discussed in https://github.com/numpy/numpy.org/pull/547#issuecomment-1028066613.

Instead of just populating the cell, we execute the code lines directly by injecting them in the console.

https://user-images.githubusercontent.com/591645/152204519-7980e9f6-ef56-4263-bb79-4fcf3e4fd2be.mp4

Right now the cell prompt is stacked on top of the cell when the width is less than 760px:

Based on this CSS in JupyterLab: https://github.com/jupyterlab/jupyterlab/blob/3.2.x/packages/cells/style/inputarea.css#L52-L68

For the console, we should override that or maybe even remove the prompt?

It would be great to be able to choose the default theme via a command line parameter.

For example the JupyterLab light and dark themes. But this would also work with other third-party themes distributed as prebuilt extensions.

Similar to #10

It should be possible to choose a different language than English via a query string parameter. For example French or Simplified Chinese.

The deployments would need to include the language packs.