jupyter-server-proxy lab extension cannot be disabled

[cmd-ntrf]

Bug description

After running the jupyter labextension disable command on jupyter-server-proxy, the extension is still being loaded.

jupyter labextension disable @jupyterlab/server-proxy

Expected behaviour

The server extension should still be loaded, but the frontend extension should not be activated when loading jupyterlab.

Actual behaviour

The jupyterlab extension is activated regardless of the enable/disable status of jupyter-server-proxy labextension status.

How to reproduce

In a virtual environment:

1. pip install jupyterlab jupyter-server-proxy jupyter-rsession-proxy
2. jupyter labextension disable @jupyterlab/server-proxy
3. jupyter lab
4. The RStudio button still shows up in Jupyterlab launcher.

More details

The reason why I want to disable the jupyterlab extension while maintaining the server extension is because I have an extension that handles the server proxy launcher items instead of jupyter-server-proxy (i.e: jupyter-lmod).

I suspect the issue stems from the way jupyter-server-proxy install its lab extension using setup.py instead of using the jupyter labextension commands. What leads me to think that is that if I try to uninstall just the lab extension of jupyter-server-proxy like this:

$ jupyter labextension uninstall @jupyterlab/server-proxy

I am greeted with the following message:

JupyterLab cannot uninstall @jupyterlab/server-proxy since it was installed outside of JupyterLab. Use the same method used to install this extension to uninstall this extension.

[bollwyvl]

A key piece is what major version of JupyterLab is involved.

labextension uninstall is for so-called "source extensions", which get built into the jupyterlab application itself with webpack and nodejs, and were the the only kind supported in JupyterLab 2.

In JupyterLab 3, which introduced "pre-built" extensions installable via pip or conda, one just needs to update some settings in the JupyterLab configuration rather than rebuilding the whole application. For more see the jupyter labextension disable command.

[cmd-ntrf]

As per the provided reproduction steps, the problem was experienced with the latest version of jupyterlab - jupyterlab 3.2.9.

[bollwyvl]

It looks like the plugin id is not, as per convention, derived from the package name, perhaps try:

jupyter labextension disable jupyterlab-server-proxy

The name should probably follow the upstream pattern, e.g. @jupyterlab/server-proxy:plugin, but shouldn't be changed until a major version bump of this package (e.g 4.0.0).

Failing that, deleting $PREFIX/share/jupyter/labextensions/@jupyterlab/server-proxy would make sure of it, but cannot be undone.

[cmd-ntrf]

Ah yes! Thank you! Using the correct plugin id did the trick.

What was counter-intuitive is that jupyter labextension list was reporting @jupyterlab/server-proxy as being installed and disabled. But I now understand that the command returns the name of the package and its state from {prefix}/etc/jupyter/labconfig/page_config.json, regardless of the actual plugin id in index.ts..

I also expiremented renaming the id to @jupyterlab/server-proxy:plugin and rebuilding the extension. The extension could then correctly be disabled with the command suggested in jupyterlab documentation, i.e:

jupyter labextension disable @jupyterlab/server-proxy

Would you like me to do a PR for the id change ? I understand it would have to sit unmerged until a 4.0 release is near.

[bollwyvl]

Yeah, a PR with the ID change would be fine... but perhaps a README or docs PR with a description of how to disable it, and warning that the ID will change, could be merged more quickly.

upstream: i feel like we should be able to disable things by the package name reported in the CLI, irrespective of what an extension author decided to call it, and kinda surprised it doesn't work that way today.

[consideRatio]

I think since its documented how to disable it, lets go with that for now and mark this issue as resolved!

Thanks everyone @cmd-ntrf and @bollwyvl!!! ❤️ 🎉