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
@adpatter if you followed the extension tutorial to install
jupyterlab_apod for JupyterLab 3.0, then you will need to uninstall it with
pip uninstall jupyterlab_apod`
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
Proceed (y/n)? y
Successfully uninstalled jupyterlab-apod-0.1.0
I was able to remove it by removing both the package and the link from the extensions directory - after running pip uninstall.
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
flit, and others probably won’t ever support putting untraceable files… somewhere in
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
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.