Repository navigation
0.7.2 regression: jupyter-kernel-client==0.8 pin (#121) breaks colab exec on PyPI installs (JupyterSubprotocol) #137
Description
Summary
The jupyter-kernel-client==0.8 pin from #121 shipped in 0.7.2, and on a PyPI install it breaks every colab exec:
AttributeError: module 'jupyter_kernel_client' has no attribute 'JupyterSubprotocol'
colab new, stop, sessions and usage still work; only kernel execution fails.
This is the failure @crichalchemist predicted in #94 (comment) (the "Second failure mode" section of their 2026-09-08 comment). Their root-cause analysis is correct and I won't repeat it. In short, [tool.uv.sources] isn't in the wheel metadata, so ==0.8 resolves to PyPI's 0.8.0 instead of the fork, and PyPI's 0.8.0 doesn't export JupyterSubprotocol. This issue just confirms that the released package is affected.
Reproduce
uv tool install google-colab-cli==0.7.2
colab new -s t # Session READY (CPU)
echo "print(1)" | colab exec -s t
# -> AttributeError: module 'jupyter_kernel_client' has no attribute 'JupyterSubprotocol'
colab stop -s tThe published wheel's metadata has only Requires-Dist: jupyter-kernel-client==0.8.
Workaround (verified)
echo "jupyter-kernel-client==0.9.0" > overrides.txt
uv tool install --reinstall --overrides overrides.txt google-colab-cli==0.7.2With it, a CPU runtime ran new → exec (prints output) → stop with no errors.
Suggested fix
Replace the pin with >=0.9 plus an upper bound that matches the client-class lookup in runtime.py, as measured in #94.
Environment
google-colab-cli 0.7.2 (PyPI), installed with uv tool install, macOS.
Activity
crichalchemist commentedon Sep 23, 2026
Thanks for confirming this against the released wheel. I reproduced it live today on current
main(e25c265): I built the wheel, installed it in isolated venvs with no mocks, and rancolab execagainst one CPU runtime:colab execKernelClientAttributeError: ... 'JupyterSubprotocol'KernelClientColabKernelClientColabKernelClientColabKernelClientAttributeError: ... 'KernelClient'(#94, addressed by #125)uv.lock)KernelClientThis isn't a uv-vs-pip issue. It affects every install from PyPI, whatever the installer: the built wheel's metadata carries only
Requires-Dist: jupyter-kernel-client==0.8, and freshuv tool install google-colab-cli==0.7.2andpip install google-colab-cli==0.7.2both resolve PyPI's 0.8.0. The[tool.uv.sources]override that points at the googlecolab fork only applies when uv installs from a source checkout (uv sync/uv runin the repo). That's why it doesn't reproduce in the dev environment.#138 has the fix. I left a review there suggesting the floor be
0.9rather than0.8: with a 0.8 floor,pip install --upgradefrom 0.7.2 keeps jkc at 0.8.0, so pip users stay broken after upgrading. uv-tool installs like yours are fixed either way.Not verified live:
colab auth/colab drivemounton theColabKernelClientpath (0.11–1.0.0), since they're interactive. Statically it's a thin subclass sending the same proxy-token header and query param, with stdin/input_replyhandling identical to the fork's.bkowshik commentedon Sep 24, 2026
Independent confirmation on macOS arm64 (Python 3.14,
uv tool install). The install upgraded to 0.7.2 on 2026-09-24, and everycolab execthen failed with theJupyterSubprotocolerror. Only the kernel commands break;new,sessionsandstopstill work. Because thecolab newpost-hook runsexec, that also broke our session bootstrap.palindromeRice commentedon Sep 25, 2026
Confirmed on macOS with google-colab-cli 0.7.2 installed via
uv tool.colab drivemountfails with:The PyPI release of
jupyter-kernel-client0.8.0 does not exportJupyterSubprotocol; 0.9.0, 1.0.0 and 1.0.2 do. Workaround until #138 lands:This resolves the AttributeError.
sethtroisi commentedon Sep 26, 2026
Thanks for the write up! I think this is now fixed after a flurry of changes today.