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

**URL:** <https://discourse.jupyter.org/t/how-do-we-uninstall-extensions-that-have-been-installed-using-jupyter-labextension-develop-overwrite/7845>\
**Category:** JupyterLab\
**Created:** [February 7, 2021, 7:03pm UTC](https://discourse.jupyter.org/t/how-do-we-uninstall-extensions-that-have-been-installed-using-jupyter-labextension-develop-overwrite/7845 "2021-02-07T19:03:12Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![adpatter](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/adpatter/32/21229_2.png) [@adpatter](https://discourse.jupyter.org/u/adpatter)\
**Post date:** [February 7, 2021, 7:03pm UTC](https://discourse.jupyter.org/t/how-do-we-uninstall-extensions-that-have-been-installed-using-jupyter-labextension-develop-overwrite/7845/1 "2021-02-07T19:03:12Z")

</div>

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](https://github.com/jupyterlab/jupyterlab/issues/9280)

---

<div class="post-metadata">

**Author:** ![jtp](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/jtp/32/19100_2.png) [@jtp](https://discourse.jupyter.org/u/jtp)\
**Post date:** [February 7, 2021, 8:02pm UTC](https://discourse.jupyter.org/t/how-do-we-uninstall-extensions-that-have-been-installed-using-jupyter-labextension-develop-overwrite/7845/2 "2021-02-07T20:02:34Z")

</div>

@adpatter if you followed the [extension tutorial](https://jupyterlab.readthedocs.io/en/stable/extension/extension_tutorial.html) to install `jupyterlab_apod` for JupyterLab 3.0, then you will need to uninstall it with `pip`:

```bash
pip uninstall jupyterlab_apod`

```

---

<div class="post-metadata">

**Author:** ![adpatter](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/adpatter/32/21229_2.png) [@adpatter](https://discourse.jupyter.org/u/adpatter)\
**Post date:** [February 7, 2021, 9:47pm UTC](https://discourse.jupyter.org/t/how-do-we-uninstall-extensions-that-have-been-installed-using-jupyter-labextension-develop-overwrite/7845/3 "2021-02-07T21:47:23Z")

</div>

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
```

---

<div class="post-metadata">

**Author:** ![adpatter](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/adpatter/32/21229_2.png) [@adpatter](https://discourse.jupyter.org/u/adpatter)\
**Post date:** [February 7, 2021, 10:10pm UTC](https://discourse.jupyter.org/t/how-do-we-uninstall-extensions-that-have-been-installed-using-jupyter-labextension-develop-overwrite/7845/4 "2021-02-07T22:10:17Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![bollwyvl](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/bollwyvl/32/904_2.png) [@bollwyvl](https://discourse.jupyter.org/u/bollwyvl)\
**Post date:** [February 9, 2021, 1:41am UTC](https://discourse.jupyter.org/t/how-do-we-uninstall-extensions-that-have-been-installed-using-jupyter-labextension-develop-overwrite/7845/5 "2021-02-09T01:41:56Z")

</div>

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](https://setuptools.readthedocs.io/en/latest/references/keywords.html?highlight=data_files#keywords), 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](https://github.com/jupyter-server/jupyter_server/issues/351), 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](https://github.com/jupyter/jupyter_core/pull/209/files#diff-e185ceb5aea025405e24e7c43c570a827b66ff50b33e43a99f2d7c66ea192316) 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_.