How do we uninstall extensions that have been installed using `jupyter labextension develop . --overwrite`?

JupyterLab
1

When I try to uninstall jupyterlab_apod, for instance, with jupyter labextension uninstall jupyterlab_apod I see the message:

JupyterLab cannot uninstall jupyterlab_apod since it was installed outside of JupyterLab. Use the same method used to install this extension to uninstall this extension.

Reference: Fix usage tests uninstalling federated extensions · Issue #9280 · jupyterlab/jupyterlab · GitHub

2

@adpatter if you followed the extension tutorial to install jupyterlab_apod for JupyterLab 3.0, then you will need to uninstall it with pip:

pip uninstall jupyterlab_apod`
3

I worked through the tutorial again. I am not able to uninstall it. It states that it has been uninstalled, but it’s still there when I start JupyterLab.

I am using 3.0.

(jupyterlab-ext) [null@localhost jupyterlab_apod]$ pip uninstall jupyterlab_apod
Found existing installation: jupyterlab-apod 0.1.0
Uninstalling jupyterlab-apod-0.1.0:
  Would remove:
    /home/null/Programs/miniconda3/envs/jupyterlab-ext/lib/python3.9/site-packages/jupyterlab-apod.egg-link
Proceed (y/n)? y
  Successfully uninstalled jupyterlab-apod-0.1.0
4

I was able to remove it by removing both the package and the link from the extensions directory - after running pip uninstall.

2 Likes
5

As discussed on gitter: so long as we rely on data_files, this issue, and a large swathe of related problems, is going to be a problem. We opted in the notebook era, when adding the conf.d approach (which made everybody a lot happier, to be sure) to continue using them, but the data_files situation hasn’t improved.

setuptools, the only python packaging tool that still supports this approach, has marked them in their official docs as deprecated, and poetry, flit, and others probably won’t ever support putting untraceable files… somewhere in sys.prefix.

These thoughts are outlined in this jupyter_server issue, with the argument against being: but it’s so nice for non-python languages and conda!. True. But the brass tacks of the matter is that we’re unlikely to get off the python/pip bus for the foreseeable future, and that bus could well leave the station at any time, and quickly.

This draft PR shows how we could move forward in a backwards-compatible way that would give python-focused package maintainers a path away from these problems. Being able to point folks to convention-based approaches like poetry and flit would make packaging for Jupyter less insular.

The biggest argument against on that PR is, it’s already too hard to keep the n jupyter --paths straight, this will make it worse! Also true! But I feel like we need to do something.

1 Like