Install either jupyter-server or jupyverse

[davidbrochart]

References

Closes #11101.

Code changes

Now that we have an official alternative Jupyter server (jupyverse), JupyterLab should not strictly depend on jupyter-server. The user should be able to install the back-end of their choice. This PR makes jupyter-server and jupyverse optional dependencies.

User-facing changes

JupyterLab should be installed with:

pip install jupyterlab[jupyter-server]
# or
pip install jupyterlab[jupyverse]

Backwards-incompatible changes

Installing with pip install jupyterlab won't be enough, and if no Jupyter server is installed, JupyterLab will show at startup:

No server installed, please install either jupyter-server or jupyverse.

[jupyterlab-probot]

Thanks for making a pull request to jupyterlab!
To try out this branch on binder, follow this link:

[jtpio]

Thanks @davidbrochart for proposing this.

Not being able to run JupyterLab anymore after a single pip install jupyterlab sounds a bit disruptive, similar to the previous question about whether to drop the dependency on ipykernel: #11958

[davidbrochart]

The other option I can think of is having a new package jupyterlab-frontend, that would mostly be the current jupyterlab package, but without the dependency on jupyter-server. The new jupyterlab package would depend on jupyter-server and jupyterlab-frontend. That way jupyverse could depend on jupyterlab-frontend without depending on jupyter-server.
What do you think?

[jtpio]

Decoupling the frontend from the backend would indeed allow for more flexibility here.

Just wondering whether introducing new packages might make the setup more complicated and increase the number of combinations. This also sounds similar to a couple of other ideas:

• extracting the build tools from jupyterlab to a separate package: Drop managing source extensions with jupyter labextension? #11336 (comment)
• introducing metapackages to install jupyterlab distribution with specific sets of features

[davidbrochart]

It would increase the number of combinations for sure (and that's the goal), but at least the "default" JupyterLab (jupyterlab-frontend + jupyter-server) would remain as easy to install.

[krassowski]

@davidbrochart during JupyterLab meeting yesterday we triaged it as something that could possibly go into 4.2 if rewritten in a way that there are no backward compatible changes (this is installing jupyterlab still gives a working jupyter-server, and importing from jupyterlab and subpackages works as it used to), which could be achieved by having the proposed jupyterlab-frontend package (which I would strongly prefer to name jupyterlab-core given that it would include CLI, extension management and other non-frontend stuff) with shim imports.

[davidbrochart]

But a jupyterlab-core with CLI and other jupyter-server-specific things will still not be a clean separation, right? In my mind, a jupyterlab-frontend with nothing backend-specific makes more sense.

[krassowski]

with CLI and other jupyter-server-specific things

CLI is not intrinsically jupyter-server specific, nor should be the extension manager etc. The fact that today these might import something from jupyter-server does it mean they should to nor need to. Things like configuration (traitlets or whatever) and contribution of assets (extensions/module federation) can be defined agnostically of the server and there is no reason why these should be in yet another place.

[davidbrochart]

I'm definitely in favor of having a configuration system that is independent of traitlets, as jupyverse uses Asphalt which in turn uses Click for the CLI and a YAML-based format for configuration files. But defining this abstraction alone could be a significant work.

[echarles]

I talked with a few users and they still want need to just pip install jupyterlab and have a fully featured installation with all the existing extensions and traitlets configuration, including the current jupyterlab and jupyter-server extensions.

[davidbrochart]

Depends what we mean by "all the extensions" and "traitlets configuration". Users surely want configuration, but I doubt they want it to use traitlets (and its custom file format) or a standard, widely used format like YAML. Jupyter-server probably has more extensions that Jupyverse at the moment, but who is going to use Tornado in a few years and in which position are we going to find ourselves if we don't embrace new technology?
I think @krassowski is right when saying that we should define an agnostic format for defining configuration and extensions. Then users can install the server of their choice, depending on which server supports which extension.

[jtpio]

@davidbrochart maybe a temporary solution could be to document (in the JupyterLab docs) how to use jupyverse as an alternative to jupyter-server?

It looks like this would otherwise involve more discussions on how to organize the different packages (and potentially the creation of metapackages).

[davidbrochart]

Thanks, I opened #16190.