Debugger always disabled with ipykernel 6.4.0?

[jtpio]

Using the latest 6.4.0 version of ipykernel, it looks like the debugger is always disabled.

This was first noticed on Binder using this gist: https://gist.github.com/jtpio/6ce26381703355e0ef1da4af742b7f72

But can be reproduced locally:

mamba create -n tmp python -y
conda activate tmp

# install the latest versions
python -m pip install -U ipykernel debugpy jupyterlab

# start JupyterLab
jupyter lab

The spec seems to be installed with debugger: false on disk:

$ cat ${CONDA_PREFIX}/share/jupyter/kernels/python3/kernel.json
{
 "argv": [
  "python",
  "-m",
  "ipykernel_launcher",
  "-f",
  "{connection_file}"
 ],
 "display_name": "Python 3 (ipykernel)",
 "language": "python",
 "metadata": {
  "debugger": false
 }
}

And the kernelspecs return debugger: false for ipykernel at startup:

Dependencies:

$ pip list | grep -E "debugpy|ipykernel"
debugpy             1.4.1
ipykernel           6.4.0

[jtpio]

Looks like this might be related to #712 and #767

[fcollonval]

The kernelspec is not dynamic; it is served from a JSON file shipped within the wheel. So the solution implemented in #767 does not work.

I would recommend reverting #767 for now as removing debugpy also break environment consistency as debugpy is still listed as mandatory dependency: #767 (comment)

[JohanMabille]

There is a field in the kernel_info reply that indicates whether a kernel supports debugging. This seems redundant with the kernelspec but it has the advantage of being dynamic.

Is there a reason for using the kernelspec instead of the kernel_info reply field in JupyterLab? Otherwise, switching to the kernel_info reply could fix this issue (although I guess it requires an additinoal patch in ipykernel).

[jtpio]

Is there a reason for using the kernelspec instead of the kernel_info reply field in JupyterLab?

Yes. The debugger extension used to use the field from the kernel_info_reply, but this led to issues for example when reloading the page. JupyterLab would attempt to send new kernel_info_request messages on startup while the kernel would be blocked, for example when blocked at a breakpoint. More info in jupyterlab/debugger#457 and jupyterlab/debugger#220.

[JohanMabille]

Thanks @jtpio!

So a possible solution to this issue could be:

• change the protocol to send the kernel_info request on the control channel to avoid freezing page refresh when the code hit a breakpoint
• rely on this field instead of the kernelspec for detecting debugging capacity.

OR

the kernelspec always sets the field in the kernelspec to True, and it's up to package maintainers who want to remove dependency on debugpy to overwrite this field when they generate the package.

[minrk]

#773 should fix the wheel metadata

I do think getting this (and all kernel capability detection) from kernel_info_reply is a better practice in general, since it's more reliably accurate than something set at build-time.

To solve the 'kernel busy on reload' issue, maybe the server should cache a first-time kernel info reply and serve that somehow without re-pinging kernels?