fix(images): bump JupyterLab to 4.6.x to resolve gallery/extension version skew

[viniciusdc]

What

Bumps JupyterLab from a hard-pinned ==4.2.5 to >=4.6.0,<4.7 in images/jupyterlab/pixi.toml, regenerates pixi.lock, and drops the now-obsolete httpx <0.28 workaround.

Why - the version skew

The image shipped JupyterLab 4.2.5, but jupyterlab-gallery==0.6.3 (and the other prebuilt extensions) were built against a much newer JupyterLab. The prebuilt federated modules declare singleton requirements the 4.2.5 core could not satisfy, so at runtime the browser console flooded with Unsatisfied version errors, e.g.:

• @jupyterlab/apputils required ^4.6.6
• @jupyterlab/coreutils required ^6.5.6
• @jupyterlab/services required ^7.5.6

The concrete user-facing symptom (issue #134): the gallery's /pull (git-clone) endpoint fails, so you cannot add contents to the Jupyter Gallery.

The fix

JupyterLab 4.6.0 (the latest stable 4.x on conda-forge / PyPI) bundles the federated packages at:

• @jupyterlab/apputils ~4.7.0 -> satisfies ^4.6.6
• @jupyterlab/coreutils ~6.6.0 -> satisfies ^6.5.6
• @jupyterlab/services ~7.6.0 -> satisfies ^7.5.6

So 4.6.0 clears every constraint the gallery 0.6.3 wheel asks for. (Note: the 4.6.6 figure in the bug report is the apputils package version; the JupyterLab app version that ships it is 4.6.0 - there is no 4.6.6 jupyterlab release.)

httpx pin lifted

The httpx <0.28 pin existed only because JupyterLab 4.2.5's extension manager (jupyterlab/extensions/pypi.py) used the proxies= kwarg that httpx 0.28 removed. JupyterLab 4.6.0's extension manager branches explicitly on the httpx version (uses mounts= for >=0.28), so the workaround is no longer needed. The comment that gated it on "until JupyterLab is upgraded" is exactly the condition we are now satisfying.

Lock regenerated

pixi.lock was regenerated (pixi lock). The resolve succeeds with no extension held back - jhub-apps==2025.11.1, jupyterlab-jhub-apps==0.3.1, jupyterlab-nebari-mode==0.3.0, jupyterlab-launchpad==1.0.5, jupyterlab_nvdashboard==0.12.0, and jupyterlab-gallery==0.6.3 all remain at their pinned versions. No extension required a JL bump or relaxation of its own.

Images affected

Both nebari-data-science-pack-jupyterlab (CPU) and nebari-data-science-pack-jupyterlab-gpu (GPU) build from the jupyterlab Dockerfile target and share this same images/jupyterlab/pixi.toml / pixi.lock env - they differ only by base image and the GPU build-arg. The fix covers both.

CI

This branch lives on the upstream repo (not a fork) so CI has access to the Quay push secret and will build + push test images for the gallery fix to be validated end-to-end (including with the GPU image).

Closes #134

[krassowski]

jupyterlab-gallery was last published way before JupyterLab 4.6.x. It is built against 4.2.x. There are no singleton requirements. Was that analysis AI-generated? I saw AI incorrectly claim these things about another extension before.