recursive package dependencies #23
Description
Problem
It seems that since #11, there is now a recursive dependency of jupyterlab_pygments on jupyterlab on jupyter_server on nbconvert on jupyterlab_pygments. Even though most of these are run-time dependencies (not build-time), this makes things complicated both for packagers and non-wheel installs on pip. Attempting a pip install --no-binary :all: jupyterlab results in:
LookupError: https://files.pythonhosted.org/packages/69/8e/8ae01f052013ee578b297499d16fcfafb892927d8e41c1a0054d2f99a569/jupyterlab_pygments-0.2.2.tar.gz (from https://pypi.org/simple/jupyterlab-pygments/) (requires-python:>=3.7) is already being built: jupyterlab-pygments from https://files.pythonhosted.org/packages/69/8e/8ae01f052013ee578b297499d16fcfafb892927d8e41c1a0054d2f99a569/jupyterlab_pygments-0.2.2.tar.gz (from nbconvert>=6.4.4->jupyter-server~=1.16->jupyterlab)
I'm not saying this is necessarily this package's fault, of course, and probably most people will be fine with wheels, but it seems worth bringing up.
Proposed Solution
If I understand #11 correctly it adds an extension. Is there a way to split off this extension part (and the dependency on jupyterlab) into a different package? Alternatively, maybe the nbconvert dependency could be removed or shifted onto a different package?
Additional context
This came up when trying to update to the latest jupyterlab_pygments with spack, which builds everything from source separately and needs to resolve dependencies, so the recursive dependencies prevent them from being installed at all (even though they are only runtime dependencies). The result is that an old version of jupyterlab_pygments (0.1.2) is installed instead, and this seems to be what some other packaging systems are doing, too.