JupyterLab concept

JupyterLab
1

Facts:

We have a centralized Python which is not writable for users. This installation has Jupyter Lab installed. Users login to RStudio and pick the JupyterLab to start a Jupyter session. In the session I can see only the basic set of extensions installed. The rest is to “Discover”.
Users also have their own Python virtual environments in their “~/venv” directory should they wish to code in Python. The env is actually a clone of the centralized Python installation.

Situation.

I was able to install a set of other extensions using the “~/venv/bin/jupyter-labextension install” command. The “~/venv/bin/jupyter-labextension list” shows a list of the new extensions in its output, but these extensions are NOT displayed in the “Installed” section of the session started by me out of the RStudio Web UI. I have my point of view of this implementation, but I’d like to compare to your experience and understanding.

Question 1

I wonder if “our” concept all is the correct approach to offer an extended behavior of the Jupyter Lab than just the basic.

Question 2

Is there a way to tell the “/centralized/Python/bin/jupyter lab” to read the extensions the user installs?

Thank you

2

You could try launching with extra_labextensions_path configured.

This can be specified at the CLI:

jupyter lab --LabConfig.extra_labextensions_path=/home/user1/venv/share/jupyter/labextensions

or in jupyter_server_config.json:

{
  "LabConfig": {
    "extra_labextensions_path": [
      "/home/user1/venv/share/jupyter/labextensions"
    ]
  }
}

Of note: this may still result in weird breakage, depending on what else your users do. For example, labextensions with serverextensions (e.g. jupyterlab-git or jupyterlab-lsp) won’t have their REST APIs available. Conservative ones generally don’t wedge the system, and have some kind of fallback… but you never know.

3

We want to be careful and let users install only lab extensions for starters.

~/venv/bin/jupyter-labextension install @jupyterlab/toc

Installed OK

~/venv/bin/jupyter labextension list returns, among the default:
@jupyterlab/toc v5.4.7 enabled OK

Executing:
/path/to/os_wide/Python/3.9.1/bin/jupyter-lab --no-browser --allow-root --ip=0.0.0.0 --LabConfig.extra_labextensions_path=/home/userxyz/venv/share/jupyter/labextensions

Result:

The “@jupyterlab/toc” is not in the “Installed”.

4

My bad, it looks like labextensions is appended; try removing that leaving just /home/userxyz/venv/share/jupyter.

5

Sorry. No success.

Upper = OS Wide
Lower = venv

os_wide-venv_2022-09-21 08_51_07-Window
os_wide-venv_2022-09-21 08_51_07-Window932×800 77.4 KB

6

One could try the $JUPYTER_PATH environment variable (and perhaps $JUPYTER_PREFER_ENV_PATH, i’m not sure how they would play out for this specific use case)… again, potentially disasterously, as there are a few extensions shown there that have serverextensions and kernel packages that need to match exactly.

Also, most jupyter subcommands support a --debug flag that will tell more about your config environment when launching. Running your test cases with these might help them reveal more things.

Also, every time I see --allow-root and 0.0.0.0, i get a little sad, as these are a great way to open an app up to serious issues.

7

Good. I’ll test.
The --allow-root and 0.0.0.0 comes from the command shown in the processes as a sub-process of started jupyter session.