I understand that Binder build the environment specified in my repo (e.g., for Python, using requirements.txt) but even with an empty specification, there’s a lot already in the Binder environment. The necessaries for Jupyter Lab, of course, but a lot more too it seems. E.g. I can import ipywidgets without error.
What Python packages are installed by Binder by default (e.g., what is itsrequirements.txt); and what additional Jupyter Lab configuration is preformed by default (e.g., what jupyter labextension install ... etc. are preformed)?
jupyterlab-offline-notebook (which provides its eponymous package)
Once you start asking for r, julia, etc. it gets… more complicated, with some packages installed from… all over. r, in particular, causes a cascading download of rstudio and a bunch of other stuff.
As of JupyterLab 3.0, there is no specific jupyterlab handling performed, as everything is handled by the pre-built extensions installed by conda (or by your requirements.txt).
From a performance perspective, you should make every effort not to use “source” extensions via jupyter lab build or jupyter labextension install in postBuild, as this will usually a) increase your build time substantially and b) reduce the reproducibility. Of course, if you have extensions you need that haven’t updated, you’ll still have to take the hit, and download 1gb+ of node_modules, run webpack, etc. then have binder push all of that trash to the various nodes.
However, if you/your users don’t use/like the giant text labels added to the notebook toolbar by jupyterlab-offline-notebook it’s “safe” (won’t invoke npm/webpack) to do jupyter labextension disable jupyterlab-offline-notebook.
Additionally, to enable jupyterlab 3.1’s collaborative features, you’ll have to do a little bit of extra work:
in requirements.txt, specify jupyterlab >=3.1 (or a specific version)
probably install jupyterlab-link-share to avoid having to root around for your token
in jupyter_config.json specify {"LabApp": {"collaborative": true}}
using this file (instead of jupyter_notebook_config.json and/or jupyter_server_config.json) avoids having to think too much about launching jupyter notebook (the default) vs jupyter lab or jupyter server
For a more concrete example, see this gist (and just not use rc2).
pip is only semi-repeatable between multiple invocations (e.g somepackage[extras] may get ignored on successive solves), so to the extent you can, you’ll want everything in one (set of) requirements.txt installed by onepip install. Same goes for conda (well, mamba) installs of environment.yml.
You can create a binder-specific configuration in a binder/ (or .binder/, which by default will be hidden in the file tree). This allows you to specify other fun demo toys… some good ones are:
the aforementioned jupyterlab-link-share
nbgitpuller, which is useful if your environment and code change less than the content you want in your demo
this works by URL parameters, and the links can get pretty long, but can be generated
jupyter-videochat for voice/video/screensharing (disclaimer: maintainer)
can also open a chat by URL parameter
You can even pre-populate multiple Lab tabs that will be open by default.
So, putting these all together, you might have something like:
/
.git/
requirements.txt # your _actual_ dependencies, ignored...
.binder/
requirements.txt # this runs first...
-r ../requirements.txt # ...bring in whatever's there
-e .. #... if you've got a setup.py
nbgitpuller
jupyterlab-link-share
jupyter-videochat
postBuild # then this...
#!/usr/bin/env bash
# though you can specify anything,
# e.g. #!/usr/bin/env python
cp .binder/jupyter_config.json .
jupyter lab workspaces import .binder/my-demo.jupyterlab-workspace
jupyter_config.json # finally, this is used at runtime
my-demo.jupyterlab-workspace
Though if you do all that, your link wil be super-duper long, and you’ll probably want to make a bit.ly out of it or something.
So if I’ve got this right, .binder/requirements.txt is cool: it basically lets me specify any additional packages I want for use specifically with Binder, w/o having to touch my requirements.txt. Is there (naive question) a way to do the equivalent with Jupyter Lab locally?
If course, you won’t have all the stuff you get from repo2docker.
If you’re on windows or an apple m1… I can only recommend trying mambaforge, and getting cozy with per-project, isolated environments, or making darned sure you have the exact proprietary compiler your most complicated package needs.