I am currently working on duplicating some of the functionality of BinderHub on an HPC system at NERSC using repo2docker. I’m starting with a git repo, pulling it locally, running repo2docker to build a Docker image, then using docker to push that to another image repository at NERSC, then running Shifter, the local HPC container tech, which pulls and converts the Docker image and loads the filesystem as read-only. There is a /tmp writable area in the container, and I can bind to other external writable volumes as well, similar to Docker.
To provide a little more detail, I’m testing this at NERSC with a JupyterHub deployment that is running jupyterlab-hub from the spawner (in my case jupyterlab-hub from inside a container). I am binding an external volume when I start the container, and I also use the ‘start’ script override from repo2docker to copy files out once the container is running that need to be writable and adjust environment variables to prevent write errors. I did some testing without JupyterHub first, and then moved to running under JupyterHub once that standalone mode was working ok for a few sample binder compatible repos. Things are a bit brute force at the moment, I’m copying out a lot that perhaps is not needed while I troubleshoot problems related to the read-only filesystem. I’ve been through the docs for repo2docker, Jupyter, JupyterLab, npm, conda, etc to track down environment variables, config files, etc.
I really started running into problems unrelated to the read-only filesystem when I was trying to test github repos that required JupyterLab extensions. After some debugging and digging, I eventually realized that the JupyterLab version from repo2docker was pinned to an older version of JupyterLab, 0.35.4 for Python 3.7, and that most of the binder repos and binder-examples seemed to be designed to run in the classic notebook interface. There is an open issue here about the JupyterLab version, repo2docker issue 724.
I did find repos that contained the code for a lab extension and worked at mybinder.org, specifically from jupytercalpoly/jupyterlab-richtext-mode, but I found others that were broken such as binder-examples/appmode. The appmode one in particular was difficult to debug, but it looks like some incompatibility between the JupyterLab version from repo2docker and the extension versions installed. Notably, there is not a pinned version of ipyvolume, which seems to be the source of the breakage, somewhere it diverged from the binder-example versions used.
Partly this has to do with a repo needing to fully specify the dependencies, which here also includes specifying the JupyterLab version needed to work. However, it would also be very useful to have a recipe for getting a particular JupyterLab extension to install correctly in a binder-like context where you can’t assume that updating everything to the latest version is an available option. If I want to install extensions X, Y, Z, which versions are compatible with each other, and is there a common JupyterLab version they would all install and run properly under? Maybe some additional dependency detection specific to JupyterLab and extensions in repo2docker could help in this particular case?
Any advice on the read-only install or JupyterLab with extensions is appreciated!