Idea: Binder + JupyterLite = BinderLite?

allow users to run arbitrary code

The good:

  • there are no extra python-side hooks that can be extended by files-on-disk
  • npm/yarn and webpack are never invoked

The bad:

  • the set of extension files (and browser kernel packages) to serve relies either on:
    • the build environment already containing all the extensions in $PREFIX/share/jupyter/labextensions/
      • this can bring in unwanted stuff
    • fully specifying the relative/absolute paths or URLs to pip .whl files or conda .tar.bz2 (as these have predictable locations in /share/jupyter/labextensions/)
      • calculating these is a huge pain… at least conda has --dry-run, but you still have to know what packages are extensions
      • getting it wrong is worse, as there is often a very tight compatibility window between “client” and “server”

The ugly

  • it is still a traitlets app under the hood, so the config loading process might find a jupyter_config.py and do something with it
  • there are a number of places where the build can ask for absolute paths, so it could ship /etc/passwd from the build machine, nicely base64-encoded for the browser.
    • this could probably be overriden

So I think you’d need to basically inherit the binder builder opinions (if not the software), but have a concept of a static folder that it was trying to build. Building static docs sites is actually a pretty sweet idea, anyway.

1 Like