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.
Problem
It seems that since #11, there is now a recursive dependency of
jupyterlab_pygmentsonjupyterlabonjupyter_serveronnbconvertonjupyterlab_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 apip install --no-binary :all: jupyterlabresults in: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 thenbconvertdependency 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.