[ExtensionApp] "standalone" mode

[SylvainCorlay]

I was looking at the extension app mechanism, and I have some thoughts for the voila use case.

• Ideally, I would like to have the voila command line to become an alias on jupyter voila. A byproduct will be that we should be able to drop the VoilaConfiguration mixin used by both the tornado application and the server extension...

• Now, one thing about the voila command line that we would lose, is the guarantee that other server extensions are not enabled. The reason is that we generally want voila to be used to produce standalone web app that don't allow arbitrary code execution. Enabling the lab server extension defeats the purpose, because it would provide a means to access and execute code...

• So an idea would be to have a --standalone option that only enables the selected server extension and not the other ones. Then voila would make use of jupyter voila --standalone...

cc @rolweber @Zsailer @epifanio

[SylvainCorlay]

Another option would be to have each extension app decide whether they allow other server extensions or not when they are used as the main extension point.

[rolweber]

I thought that the selected app is responsible for enabling all extensions that should be running, besides the default stuff that comes with Jupyter Server itself. So if the Voila extension doesn't enable Lab, then Lab isn't there. Am I mistaken there?

[vidartf]

Ideally, I would like to have the voila command line to become an alias on jupyter voila.

Just for context, what is the motivation for this?

[SylvainCorlay]

Just for context, what is the motivation for this?

This would reduce the number of entry points and simplify the codebase (e.g. no need for a VoilaConfiguration object).

[SylvainCorlay]

In a way, voila and lab are two perfect examples of extension apps...

[Zsailer]

In the current ExtensionApp class, VoilaConfiguration already goes away (I desperately need to add documentation to demonstrate this).

In PR #59, I added logic to handle the extension-specific config. That way, extensions writers don't need to write their own mixin classes (like VoilaConfiguration).

How does this work?

• ExtensionApp creates a Configurable object to store the extension's trait
• It then passes this object to tornado web-servers settings under the '<extension_name>_config' key.
• If the extensions' handlers inherit the provided ExtensionHandler class, this object is accessible under the handler's self.config attribute.

[Zsailer]

I'm also fine with adding a --standalone mode.

[SylvainCorlay]

In the current ExtensionApp class, VoilaConfiguration already goes away (I desperately need to add documentation to demonstrate this).

Yep, but I guess this requires the voila command line to be an alias on jupyter voila.

I'm also fine with adding a --standalone mode.

👍

[Zsailer]

Yep, but I guess this requires the voila command line to be an alias on jupyter voila.

I think you're right.

You could, instead, have a small subclass that inherits the Voila ExtensionApp, changes the standalone trait to True, set this trait's tag config=False, and add a new voila entry-point pointing to this classes launch_instance method.

[Zsailer]

Adding in #70

[Zsailer]

We added the option for ExtensionApps to shut off other extensions in #76

[Zsailer]

Closing since we added standalone mode in #76.