JupyterHub integration

[blink1073]

References

Fixes #6428.

cf jupyterhub/jupyterlab-hub#84
cf #6399

Code changes

Absorbs labhubapp and jupyterlab-hub into the main application.

User-facing changes

No longer need to provide any additional config other than setting c.Spawner.default_url = '/lab', and no need to install jupyterlab-hub.

Backwards-incompatible changes

Deprecated SingleUserLabApp.

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[blink1073]

@ian-r-rose, do you mind finishing this PR with the connection lost handling?

[blink1073]

@ian-r-rose, ping!

[ian-r-rose]

@blink1073 Sure, I can do that.

[blink1073]

Thanks! ❤️

[ian-r-rose]

I'm currently fixing up some stuff on the Python side -- still not completely running yet.

[ian-r-rose]

This check doesn't appear to be working, at least not in my testing. At the time the server extension is loaded, it doesn't seem like the hub_prefix traitlet has been set.

labhubapp.py seems to be working correctly.

[ian-r-rose]

I'm concerned that we won't actually be able to deprecate LabHubApp. Without it, I'm not sure that JupyterHub spawners can easily configure the LabApp specific traitlets (which is a problem I'm having while testing this).

[blink1073]

I'm not sure why you saw this state. I'm seeing it working fine locally...

[blink1073]

It is working for me in it's current state. Here is the relevant config I'm using:

c.Spawner.default_url = '/lab'
c.Spawner.environment = { 'JUPYTERLAB_DIR': '/home/silvester/workspace/jupyter/lab/dev_mode' }

[blink1073]

Thanks @ian-r-rose! Not sure about the CI failure, Usage has been flakey...

[Zsailer]

@ian-r-rose I may be wrong, but I don't think this problem should happen if traits are added in appropriate config files. Traits in config files should get loaded by the respective classes.

The problem here is that traits passed to the main application being launched by the CLI don't get directed to the classes to which they belong unless those classes are explicitly added to main applications' classes trait.

[ian-r-rose]

@Zsailer My grasp of traitlet loading is definitely pretty shaky, but I was having trouble getting that to work when testing this. My thinking was this: if JupyterHub is using the default SingleUserNotebookApp, then nowhere is a LabApp actually instantiated, and therefore those configurables never get read in from a config file. This is despite the fact that the JupyterLab server extension is activated. Am I missing something?

[blink1073]

Hmm, yeah, configuring an extension itself is really what we want, not an app. If you wanted to configure an app then you should be using that app directly.

[blink1073]

In my ideal world, I think all extensions would be classes, and not use the load_serverextension magic function but something like an import path to the class as the extension load mechanism.

[blink1073]

@ian-r-rose, the error was the fact that we were implicitly relying on the hub extension in our application extension. I added a fallback to the default connectionLost implementation.

[blink1073]

JS failure is unrelated, and the windows one passed, so in she goes. Thanks again @ian-r-rose!

[Zsailer]

In my ideal world, I think all extensions would be classes, and not use the load_serverextension magic function but something like an import path to the class as the extension load mechanism.

I'm not sure about the history behind the load_jupyter_server_extension, but your suggestion above seems like a good idea. My guess is that for simple server extensions that add a couple and endpoints+handlers, the load_jupyter_server_extension offered a simple plugin mechanism.

More complex extensions would benefit from an import path to class mechanism. jupyter-server/jupyter_server#48 is a compromise of those two solutions. It uses some tricky logic to hijack load_jupyter_server_extension mechanism add configurable extensions. The downside is that we don't get the ability to configure extensions from the jupyter server CLI. Instead, extensions would be configured by their separate config files.

Should we drop the load_jupyter_server_extension mechanism? Or is this still useful for simple extensions?

[Zsailer]

nowhere is a LabApp actually instantiated

@ian-r-rose Ah yes. You're right. I was thinking ahead to a world where hub is launching jupyter_server ServerApps and lab is loaded as a server extension. In that world, LabApp is instantiated and configured from file; however, it (currently) cannot be configured from jupyter_server's CLI.

[consideRatio]

Wieeeeeeeeeeeee sooo much excellent work going on ❤️ 🎉! This is awesome!!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related discussion.