Jupyter reports extension errors for mystery extensions

Even in a completely pristine virtual environment I get errors of the following form

Package jupyter_server_terminals took 0.0020s to import
[W 2023-09-14 09:17:01.917 ServerApp] NAME | error adding extension (enabled: True): The module 'NAME' could not be found (No module named 'NAME'). Are you sure the extension is installed?
    Traceback (most recent call last):
      File "/Users/Rax/Documents/Projects/Coding/Python/venvs/automata/lib/python3.11/site-packages/jupyter_server/extension/manager.py", line 319, in add_extension
        extpkg = ExtensionPackage(name=extension_name, enabled=enabled)
      File "/Users/Rax/Documents/Projects/Coding/Python/venvs/automata/lib/python3.11/site-packages/jupyter_server/extension/manager.py", line 183, in __init__
      File "/Users/Rax/Documents/Projects/Coding/Python/venvs/automata/lib/python3.11/site-packages/jupyter_server/extension/manager.py", line 198, in _load_metadata
        raise ExtensionModuleNotFound(msg) from None
    jupyter_server.extension.utils.ExtensionModuleNotFound: The module ’NAME' could not be found (No module named ’NAME'). Are you sure the extension is installed?


  • jupyter_server_fileid
  • jupyter_server_mathjax
  • jupyter_server_ydoc
  • jupyterlab_git
  • nbclassic
  • nbdime

My requirements include none of these packages, and none are installed, all I have is

notebook >=7.0   

Why is Jupyter looking for these extensions in the first place? How do I prevent these warnings?

This might provide more actionable information:

jupyter server extension list --debug

One can also check (and potentially clean up) other places configuration might be stored:

jupyter --paths

Some (older) extensions suggest the --user option in some places, which may no longer work or be installed… generally you’ll want your package manager to take care of marshalling the jupyter_server_config.d files, but can still happen.

1 Like

There seems to be an alternate universe from years ago in


that has configs for the offending extensions. I assume I should just delete that and see what happens?

sure, could back it up first, i guess…

That works, if I delete it and then rebuild the virtual environment from scratch.Though now jupyterlab_pygments reappears (of course, because something is installing it as a dependency?) and I have a choice between

        jupyterlab_pygments v0.2.2 enabled  X (python, jupyterlab_pygments)


500 GET /api/nbconvert?1694719524544 (::1): Could not import nbconvert: No module named 'jupyterlab_pygments'
[W 2023-09-14 15:25:24.610 ServerApp] wrote error: "Could not import nbconvert: No module named 'jupyterlab_pygments'"
ile "/Users/Rax/Documents/Projects/Coding/Python/venvs/automata/lib/python3.11/site-packages/jupyter_server/services/nbconvert/handlers.py", line 36, in get
        raise web.HTTPError(500, "Could not import nbconvert: %s" % e) from e
    tornado.web.HTTPError: HTTP 500: Internal Server Error (Could not import nbconvert: No module named 'jupyterlab_pygments')

The former right after making the clean virtual environment, and the latter if I relaunch after uninstalling using the extension manager,

This is a known issue, but the :x: will not actually break anything, while uninstalling a dependency certainly will.

1 Like

Not uninstalling the dependency: uninstalling the extension with the extension manager. (Are they not different things?)

So the question then becomes which of the two errors should I prefer? The X or uninstalling the extension?

Have a look at pip list: the behavior of the new extension manager does uninstall the underlying python package now.

And yes, I’d wager a cosmetic :x: is likely preferrable to “can’t nbconvert at all.”

1 Like

Ah, so uninstalling the extension in the extension manager uninstalls the package? I didn’t know that. Definitely the wrong UX. (And jupyterlab_pygments not nbconvert right?)