JupyterLab concept

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

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.

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”.

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

Sorry. No success.

Upper = OS Wide
Lower = venv

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.

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.