[MRG] link server extension subcommands to main app

[Zsailer]

Here is a different way of accomplishing #151. @echarles

This creates a new subapp, jupyter server extension, with multiple subcommands:

• jupyter server extension list: lists all server extensions
• jupyter server extension enable <name>: enables an extension
• jupyter server extension disable <name>: disables an extension.

@vidartf @dhirschfeld @rolweber, what do you think?

[rolweber]

I don't have time to review the code, but the user interface is much better this way. Thanks!

[echarles]

Thx @Zsailer. Haven't tried to run these changes, but from a quick look at the code, the old jupyter serverextension list will not be supported anymore. Correct? If this is the case, I wonder if it is a feature or something to fix. To avoid confusion, I would say it is a feature.

A second question is the ability to list the ExtensionApp. Current implementation do not list them (in other words, the installed json are not taken into account) and I do not see any change here to list them. Maybe we need to forsee an additional syntax like jupyter server extension-app <command> and implement that in another PR?

[Zsailer]

There's some inconsistency on the default location for extension when listing, enabling, and disabling extensions. In the JEP, we propose defaulting to --sys-prefix, but we use a mix of --user | --sys-prefix. I'm going to standardize on what we propose in the JEP, --sys-prefix.

[echarles]

Hi Zach, I guess you are referring to jupyter/enhancement-proposals#33 where you propose --sys-prefix as default. Out of curiosity, is the current mix of user | --sys-prefix also present in notebook?

Is the intent to implement in this PR the search for json in all folders under the folders returned by jupyter_path('jupyter_server_config.d') so that the 3 actions (list, enable, disable) take these into account?

[Zsailer]

I guess you are referring to jupyter/enhancement-proposals#33 where you propose --sys-prefix as default

👍

is the current mix of user | --sys-prefix also present in notebook?

It looks like notebook consistently chooses user. When we made the fork, we changed some of these defaults, but not all, to sys-prefix. I'm going to try to make these changes consistent in this PR.

Is the intent to implement in this PR the search for json in all folders under the folders returned by jupyter_path('jupyter_server_config.d')

Yes. 😃 That's the goal.

[Zsailer]

While working on this further, I'm finding our extension subapp is quite brittle. For example, you can enable an extension that doesn't actually exist (i.e. not installed or importable). There is some validation that happens, but the extension will still be added to a config file and set to enabled even if the validation fails...

This has led me to do a minor refactor of our extension listing/enabling/disabling mechanism. I'll update this PR soon.

[Zsailer]

Ok, I've refactored the jupyter server extension subapp logic quite a bit.

1. First, I've bundled everything under the extension submodule (where the ExtensionApp lives). All extensions use this mechanism so it made the most sense to have one "extension" submodule (we had two before, extensions and extension... confusing!).

2. I've moved logging logic from the toggle_server_extension and validate_server_extension to the server extension application. It didn't make sense to me that logging happens in these functions where a logger might not be present. All logging should happen in the application itself.

3. I've gone through each place in the extension application module and set the default locations for enabling/disabling to sys-prefix.

4. I've updated tests to verify things work as expected.

5. I added a pytest extension to test the jupyter server extension entrypoint. This can also be used if we want to write tests for the other entrypoints in this library.

This is ready for review. Pinging @echarles or @vidartf 😃

[echarles]

I have installed nbclassic and 3 simple extension-apps. jupyter server extension list prints the expected output.

config dir: /opt/miniconda3/envs/datalayer/etc/jupyter
    nbclassic enabled
    - Validating nbclassic...
      nbclassic  OK
    simple_ext1 enabled
    - Validating simple_ext1...
      simple_ext1  OK
    simple_ext11 enabled
    - Validating simple_ext11...
      simple_ext11  OK
    simple_ext2 enabled
    - Validating simple_ext2...
      simple_ext2  OK

Then I have run jupyter serverextension enable --py jupyterlab_git as documented in the jupyterlab-git, which prints as output.

Enabling: jupyterlab_git
- Writing config: /Users/echar4/.jupyter
    - Validating...
      jupyterlab_git  OK

The jupyter server extension list returns the same initial result but does not include the jupyterlab_git extension. Also with jupyter serverextension enable --sys-prefix jupyterlab_git, the jupyterlab_git entry is not listed.

To summarize, the listing only contains the ExtensionApps, but not the former server extensions. Maybe this is the expected behavior? In that case, I would prefer having to invoke jupyter server extension-app list.

[echarles]

PS: jupyter serverextension list continues working as before, only returning the former server extension, without the new extensionapps.

[echarles]

Just discussed the above question related to old and new extensions. The old ones are not listed because they reside under the jupyter_notebook_config.d (and also don't have the correct stanza anyway). We decided during the jupyter server meeting to forsee a migration process (one time or not) that would allow to migrate the old content to the new content. This would be implemented in nbclassic or in server (to be discussed).

[echarles]

LGTM