Allow some code to be silently pre-run in the `repl` app

Problem

Now that #498 has been merged and the repl app has been added, I’d like to raise the same issue as I raised in https://github.com/jtpio/replite/pull/24 to allow some code to be silently pre-run before handing over the app to the user. I’m opening a separate issue from #461, because I think the issues are slightly different between pre-running code in the repl and pre-running code in notebooks.

It seems to me that one of the main uses of the repl app is to embed it to allow people to try out code without having to install it. For example, @jtpio made a PR (https://github.com/numpy/numpy.org/pull/547) in numpy.org to use this repl app for numpy’s ‘Try numpy’ feature. However, because pyodide only contains a small subset of Python packages and, in particular, pyodide does not want to add Python packages that have a pure Python wheel, for most packages users have to do

import micropip # or using piplite
await micropip.install('PACKAGE')

before they can import PACKAGE. This code could be pre-populated using the code URL parameter, but I think that would be confusing for end users, because:

• Users expect this to be Python code, but this code can’t actually be run in a Python interpreter;
• They are often novice Python users and will be very confused by the await keyword, which isn’t part of Python

I’d love to use the repl app to make ‘Try numpy’ like REPLs for my Python packages’ documentation, but showing the import micropip... code is a non-starter, since it will just lead to more confusion than it’s worth among my users (who are often novice Python users). I think it’s easy enough to add a disclaimer that the shown REPL isn’t a full Python environment, so not everything will work as normal.

Proposed Solution

Add a URL parameter similar to the prerun parameter from https://github.com/jtpio/replite/pull/24 that allows code that is to be pre-run to be added at runtime.

Discussion

Alternative solutions

• Don’t allow arbitrary code to be pre-run, only install packages. E.g., my original PR in https://github.com/jtpio/replite/pull/24 added a install URL parameter that listed packages to be installed by micropip. @jtpio objected (reasonably) to this, because micropip is specific to the pyolite kernel, while the repl app supports many kernels. However, one could also make it a python_install URL parameter or pyolite_install parameter to make it clear that it’s only to be used for pyolite kernels
• Somehow catch all instances of import PACKAGE that fail and try to do import micropip; await micropip.install('PACKAGE'); install PACKAGE as a fall-back. Downside of this is that it only allows packages to be installed that are on PyPI, not wheels hosted elsewhere.
• An extension that does the proposed solution. If this is the preferred option, I’d appreciate some pointers on how to do this, because I have no idea!

Reproducibility and user confusion

Some issues were raised in #461 that are worth addressing here. I think the main ones are:

1. Reproducibility: having code silently pre-run makes it confusing to the run same code on another instance of the repl that doesn’t pre-run this code
2. You can only hide that you are running in pyolite rather than Python for so long and users might have to learn pyolite to import other packages that they might need (or fetch files over HTTPS etc.)

I think reproducibility is a lesser concern for the repl app, because there is no notebook to download and run elsewhere. And I think these repls will generally be used in a context where it’s clear to the user that it is a special case (e.g., the ‘Try numpy’ repl).

There’s no way around 2. really, but I imagine that users will not generally be tempted to try to install packages that don’t just load, say in the context of a Try numpy-like REPL. Embedded REPLs can just add a disclaimer about things not fully working as usual.

[jobovy]

This isn’t getting much traction it seems, but if anybody reading this is interested in this functionality, note that I’ve implemented it in jobovy/jupyterlite:quiet-prerun. This simply adds the prerun URL parameter to the repl app, as described in my proposed solution. It’s a stopgap until somebody writes an extension to do this.

I also have an example of using this to deploy a REPL with a bunch of code to pre-run at jobovy/galpy-repl, which builds the custom jupyterlite REPL and deploys it to AWS S3 together with a repl shortcut that includes the code to pre-run (see the README of that repository for more explanation of this).

[psychemedia]

Minimising complexity and confusion for new users is key where the REPL, or demo notebooks, are used to onboard new users.

The await and micropip requirements distinguish the juptyerlite code from non-Jupyterlite Python environments; one way round this would be to support package installation via %pip as per https://github.com/jupyterlite/jupyterlite/issues/237 / This is magic after all, so the user needn’t know what’s going on underneath.

For pre-run code such as package imports, is there a way to do this verbosely, for example display a line prior to the first cursor saying something like “This environment has been pre-configured by pre-importing the X and Y packages”, or some formulation that also accommodates from .... import ... formulations.