Location of libraries or extensions installed in JupyterLab

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?

Thanks,
Rakesh.

%pip and %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.

The shell !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.

2 Likes