jupyter-server-proxy lab extension cannot be disabled

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]

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.

[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.