[BUG] - Cannot installing JupyterLab extensions on deployments without swapping docker image

[krassowski]

Describe the bug

Recent PR #2191 disabled global use of pip. The default Extension Manager in JupyterLab 4.0+ uses PyPI as registry and pip as underlying command to install extensions (although for extensions which are frontend only it really is language and packager agnostic).

It is currently impossible to install a JupyterLab extension.

• users cannot install extensions at all
• deployment operators/admins have to modify the docker image to install an extension

Three weeks ago I opened nebari-dev/nebari-docker-images#120 to add jupyterlab-favourites which is needed for one of the deployments. Well actually, we just want to evaluate it. It should not take months to evaluate a single extension.

This is what user sees today when they try to use the Extension Manager:

Expected behavior

Either:

• the default Extension Manager (PyPI-backed) works, or
• jupyterlab-conda-store provides custom Extension Manager which works in the constraints of nebari (see [ENH] - Integrating with the native JupyterLab extension manager  conda-incubator/jupyterlab-conda-store#40 proposal), or
• there is at least some mechanism for admins to install extensions nebari-config.yml?) and the Readonly Extension Manager is used to avoid confusing the user

OS and architecture in which you are running Nebari

latest

How to Reproduce the problem?

Try to install an extension

Command output

No response

Versions and dependencies used.

No response

Compute environment

None

Integrations

No response

Anything else?

No response

[krassowski]

The ability to install jupyterlab extensions via conda store was listed as long term plan in: nebari-dev/governance#22 (comment) so I assume this is planned?

[Adam-D-Lewis]

Even if we allow users to install extension, it seems like we should be able to disable that in case an org doesn't want their users to install extensions. It seems like there are some potential security concerns around extensions, is that right?

[krassowski]

we should be able to disable that in case an org doesn't want their users to install extensions

That can be done or multiple levels. JupyterLab offers granular ability to define an allow list of plugins, block list of plugins, lock the plugin enabled/disabled state, or even disable extension manager outright. All of that can be controlled from the config files which are already used be nebari, we would just needs to setup the config.

[dharhas]

The ability to install jupyterlab extensions via conda store was listed as long term plan in: nebari-dev/governance#22 (comment) so I assume this is planned?

I would say it is desired but no-one has investigated what would require to implement. Adding this would be high value and we could address security considerations with documentation/examples of how to enable/disable things in nebari/jupyter config.