Custom manager classes in both notebook vs. jupyter_server

[kevin-bates]

Currently, the way we check the *_manager_class traits (i.e. kernel_manager_class, contents_manager_class, etc.) prevents anyone from creating a custom class that works with both notebook and jupyter_server. That's because the Type() trait checks that the custom class inherits from a manager of one of these packages, not both.

You will either see:

The 'contents_manager_class' trait of a ServerApp instance expected a subclass of 'jupyter_server.services.contents.manager.ContentsManager', ...

if you inherit the base class from notebook, or

The 'contents_manager_class' trait of a NotebookApp instance expected a subclass of 'notebook.services.contents.manager.ContentsManager',

if you inherit from jupyter_server. There is no way to make a manager compatible with both servers.

This is something we'll likely want nbclassic to address, since it acts as the bridge between the two packages.

[kevin-bates]

After thinking about this further, I think this may only apply (practically speaking) to custom contents managers.

[mwouts]

Yes this is an issue that we encountered for Jupytext, and we found no other solution than building the contents manager class dynamically from the current contents manager:

https://github.com/mwouts/jupytext/blob/d2898da3771d224bab3c15a2ea3e8e6e30a20423/jupytext/__init__.py#L40-L42

In practice it works well, but maybe that's not the best design... happy to learn of better workarounds!

[vidartf]

We could maybe do something similar to this?

https://github.com/jupyter/nbdime/blob/c82362344e596efdc4f54c927d90338940e0fa41/nbdime/webapp/nb_server_extension.py#L16-L33

[kevin-bates]

Looks like this is getting handled in the respective server bases (jupyter-server/jupyter_server#392, jupyter/notebook#5957 which makes sense.