Restore nbgitpuller, dropped as collateral of the JupyterLab 4 upgrade in #317

[audiodude]

What

Re-adds nbgitpuller>=1.2 to the singleuser image (one requirement line, plus a comment explaining the floor).

Why

nbgitpuller was added in #66 (May 2021) so that /hub/user-redirect/git-pull?repo=...&urlpath=... links could pull a repo into a user's PAWS home and open a notebook in one click — the standard way to put an "open this example on PAWS" link on a wiki page.

Why it was removed

Not for its own sake — it was collateral of the JupyterLab 4 upgrade in #317, which also dropped the notebook pin and left nbgitpuller 1.1.1's notebook>=5.5.0 pulling in notebook 7. Full history, and why removing it was never necessary, in T434973.

Current behavior (verified 2026-08-13): clicking a git-pull link resolves through the hub, then 404s on the user server, e.g.

https://hub-paws.wmcloud.org/user/<name>/git-pull?repo=...  →  404

because nothing in the image registers the git-pull handler. Confirmed absent from images/singleuser/{Dockerfile,requirements.txt,install-extensions} on main.

Compatibility

nbgitpuller 1.2.0 (2023-08-07) dropped the notebook dependency, and 1.3.0 declares only jupyter_server>=1.10.1 and tornado. It ships no JupyterLab prebuilt extension in any version — it is a jupyter_server extension — so there is no JupyterLab version coupling; the image's jupyterlab 4.4.0 pulls jupyter_server>=2.4, well above the floor. The image no longer installs notebook at all (that pin went in #324).

The requirement is written >=1.2 so that no future resolution can land on ≤1.1.1 and reintroduce the notebook dependency that caused the 2023 breakage.

🤖 Generated with Claude Code
Manually reviewed by @audiodude

[audiodude]

Rebased onto current main (8ba5cd0, #529) — now at b324854, no conflicts; this PR only touches images/singleuser/requirements.txt and #529 touched the Dockerfile and values.yaml.

The two red checks are unrelated to the change itself, but we want to flag a consequence that needs a maintainer either way.

Both failures are the fork-checkout guard in actions/checkout:

Refusing to check out fork pull request code from a 'pull_request_target'
workflow. ... To opt in, review the risks at
https://gh.io/securely-using-pull_request_target and set
'allow-unsafe-pr-checkout: true' on the actions/checkout step.

update-container-tags.yaml and singleuser.yaml are both pull_request_target, and the former checks out head.repo.full_name explicitly, so neither can run for a PR from a fork. Both fail in ~4s at the checkout step, before building anything. This isn't specific to our branch — it should hit any fork PR touching images/.

The part that matters beyond the red X: update-container-tags is what rewrites

tag: pr-529 # singleuser tag managed by github actions

in paws/values.yaml, and singleuser.yaml is what builds and pushes that image to quay. Since neither runs here, merging this as-is would not deploy nbgitpuller — values.yaml would keep pointing at pr-529, which was built before this commit existed.

Easiest path, if you agree the change is wanted: push the branch inside toolforge/paws and open it from there, so both workflows run in-repo. It's a 4-line addition to images/singleuser/requirements.txt, so cherry-picking b324854 is trivial and we don't mind at all if this PR gets closed in favour of that. Otherwise it needs a manual singleuser tag bump alongside the merge. We'd rather not suggest allow-unsafe-pr-checkout: true, since that's exactly the pwn-request opt-in the guard exists to prevent.

Also, linter and tofu fmt are sitting at action_required pending workflow approval, so those two haven't reported yet.

_{"We" here is @audiodude — @Audiodude on Phabricator — and Claude Code, which assisted with the rebase and CI triage; claims above are drawn from the workflow files and the job logs for b324854.}