I would like to understand some details about the extensions and external libraries installed in a JupyterLab environment. Specifically, I’d like to understand the location where such libraries are installed when someone does
pip install <library>. Are these libraries installed in the Jupyter server or are they installed in the ipython kernel? Given that it is possible to connect to a remote kernel from JupyterLab, where are the libraries installed in that case? Currently, I have JupyterLab setup on my machine where the Jupyter server and the ipython kernel are present on the same machine. In the case where the kernel resides on a different machine from the Jupyter server, where are the library files installed? If they are installed on the Jupyter server, are they transferred over to the machine where the ipython kernel is running?
%conda will always install in the same environment as the kernel that’s running. If that is the same environment as
jupyterlab, the static files will be available when next loaded.
!pip will install… wherever. It’s a bit hard to say, as it depends on how the kernel was installed, launched, etc.
No special handling exists to move files between python environments on different hosts, though “static files hosted by a kernel” have been long desired, and have lead some communities like
julia to implement a “files-over-comms” approach (similar to how ipywidgets work).
Extensions that have a serverextension component would be particularly inconvenient, as these always require a server restart.
For static files in
$PREFIX/share/jupyter/labextensions, it would theoretically be possible to create a
jupyterlab_server_remoteextensions that allowed for making these part of the same virtual file tree, but is unlikely to land in core.
jupyterlab is designed to be less “hot swappable” in a running app than classic
notebook, and doesn’t have a
require.js-equivalent, and tools like jupyterlab-plugin-playground are needed to overcome some of this. It’s possible a future version will allow more dynamic plugin registration and de-registration, but this has many properties of a package manager.