Use the kernel spec metadata['debugger'] to check if a kernel supports debugging

[jtpio]

Fixes #220.
Alternative to #456 (see this comment: #456 (comment))

The issue is that at the moment the kernel_info_request message is sent on the shell channel. If the execution has stopped (breakpoint hit), the debugger frontend forever waits for the kernel_info_reply to decide whether the kernel supports debugging or not, because the debugger key is in the kernel info reply.

Instead of waiting for the kernel_info_reply, the debugger frontend now checks the kernel spec to know if a kernel supports debugging or not.

This change requires the following change to the kernel spec, and the kernels (for now only xeus-python) would have to implement that change too:

EDIT: this has been added to xeus-python=0.8.0 (jupyter-xeus/xeus-python#282):

cat ${CONDA_PREFIX}/share/jupyter/kernels/xpython/kernel.json

{
  "display_name": "xpython",
  "argv": [
      "/home/jtp/miniconda/envs/debugger/bin/xpython",
      "-f",
      "{connection_file}"
  ],
  "language": "python",
  "metadata": { "debugger": true }
}

Visually the result looks similar as in #456, except that there is no need for a timeout anymore:

This would also require an update to the sequence diagram in #64.

[jtpio]

We might want to make this optional, so instantiating a DebuggerService without a kernel specs manager would always assume debugging is enabled (for example in an custom JupyterFrontEnd where only one kernel is available).

[jtpio]

cc @JohanMabille @afshin

Leaving it as a draft for now as it would require changes to xeus-python.

This is something we already discussed before. It looks like having the debugger key in the kernel spec metadata is cleaner than what is implemented in #456.

Also if we go for this or #456, the debugger key wouldn't be strictly needed in the kernel_info_reply anymore (jupyter/jupyter_client#486).

[afshin]

I think it's reasonable for a kernel that supports DAP to have metadata that says it supports debugging. This seems like the fastest route to get that information and it also seems the least kernel-traffic-dependent way of doing it. I support this approach over the other PR.

[JohanMabille]

I totally agree with @afshin and @jtpio, this is cleaner than sending a request to the kernel. I will implement the change in xeus-python quickly.

[jtpio]

It looks like we need to mock the KernelSpecManager instance used in the tests, similar to what is done in core lab: https://github.com/jupyterlab/jupyterlab/blob/b1e2b83047421bf7196bec5f2a94d0616dcb2329/packages/services/test/kernelspec/manager.spec.ts#L17-L25

Retrieving the specs from the local jupyter server (child process) would otherwise return a 403, as the token is generated when the JupyterServer is started here.

[afshin]

Thanks! This is a much nicer way to detect debugger functionality.

👍

[kycutler]

Is this documented anywhere? I see the debugger flag documented in kernel info here, but nothing about the flag in kernelspecs.