[ENH] - Ability to install JupyterLab Extensions without updating base docker image

[aktech]

Feature description

Implement ability to install JupyterLab Extensions without updating base docker image.

UPDATE: @krassowski and I had a chat today regarding potential ideas on how to do this. Here are the notes and potential (proposed) architecture:

JHub Apps (Too much freedom to the user)

One potential architecture is with JHub Apps, with the ability to spin-up multiple JupyterLab instances, one can create a conda-store environment with all the extensions they need in that environment and spinup JupyterLab in that environment.
requires extensions to be installable conda - not really a problem

• Gives too much control to the environment - installing arbitrary things, would be a no-go for enterprise and govt deployments
• Possibility to remove telemetry like jupyterlab-pioneer
• Possibility to inject some packages in spawn sequence

Extension Manager + JHub Apps

Proposed Workflow:

• Frontend only extensions: Users will be able to install any (except added in disallowed list or only allowed if allowed list is present) frontend extensions easily via conda-store environment and chose it in the Extension Manager in JupyterLab.
• Server Side extensions: For server side extension users would need to ask admin to give them access to a conda-store environment which has that server side extension installed, then they can use that environment to create JupyterLab via JHub Apps in that particular conda-store environment. This is to avoid security of allowing installation of any server side extension.

Notes:

• We can extend JupyterLab's extension manager such that to load frontend extensions from conda-store environment, specified by the user, people will be able to install any frontend extensions.
• JupyterLab has the ability to filter extensions via allow/disallow even for frontend extensions.
• Reg JupyterLab Extension manager
  • We can make it install to default conda environment (ignoring conda-store)
    • If we do that the default env can break it
    • It will apply to all environments
  • Can we have a smart extension manager enabling extensions on per conda-store environment basis
    • This would only work for frontend extensions
    • UI control “use extensions from this/that conda-store env”
    • The extensions can still break environment

Value and/or benefit

The users will have more freedom to install extensions of their choice without being limited by what's provided in the base docker image.

Anything else?

Relevant issues:

• [BUG] - Cannot installing JupyterLab extensions on deployments without swapping docker image #2299
• [ENH] - Integrating with the native JupyterLab extension manager  conda-incubator/jupyterlab-conda-store#40

No response

[krassowski]

How the frontend extension source selection could look like:

This will allow users to switch frontend extensions source when switching between projects which require different versions of the visualisation libraries, or for different groups to cooperate on the same nebari instance while using different versions of visualisation libraries.

Alternatively, it would also allow advanced users to create a dedicated environment for jupyterlab extensions only.

Changing the environment would require the user to refresh the page but this is acceptable as this is common with other settings in JupyterLab and all pains will go away once we switch on server-side execution (which preserves outputs when frontend is disconnected).