JEP for copy-to-globals support in debugger_info

[brichet]

Introducing a new field to the kernel debugger_info response.
This new field will inform the UI that the debugger supports the copyToGlobals request.

Related to jupyterlab/jupyterlab#13476 (comment), which introduces a new feature in the debugger. It would be useful to know if this feature is supported by the kernel from UI side.

cc. @JohanMabille @krassowski

Voting from @jupyter/software-steering-council

• @echarles
  • Yes
  • No
  • Abstain
• @fcollonval
  • Yes
  • No
  • Abstain
• @gabalafou
  • Yes
  • No
  • Abstain
• @ibdafna
  • Yes
  • No
  • Abstain
• @ivanov
  • Yes
  • No
  • Abstain
• @JohanMabille
  • Yes
  • No
  • Abstain
• @marthacryan
  • Yes
  • No
  • Abstain
• @minrk
  • Yes
  • No
  • Abstain
• @rpwagner
  • Yes
  • No
  • Abstain
• @SylvainCorlay
  • Yes
  • No
  • Abstain
• @Zsailer
  • Yes
  • No
  • Abstain

[JohanMabille]

+1 on this, it has a very limited impact on the protocol and is backward compatible.

[krassowski]

Would not it be more in line with DAP to advertise it via capabilities of initialize request response? For example, "copy to clipboard" can be implemented relying on supportsClipboardContext?: boolean;.

I see that this would require modifying the message in flight, but it seems cleaner on the API side.

[krassowski]

I guess the same goes for richRendering (which we have not codified so far).

[krassowski]

I guess the same goes for richRendering (which we have not codified so far).

[brichet]

Thanks @krassowski

These "capabilities" are really kernel capabilities, and not debugger capabilities. I'm more in favor of separating the 2 types of capabilities, for clarity. An other solution could be to add a capabilities object in the debugInfo response, but that would not be backward compatible.

If I am not mistaken, all requests/responses defined in DAP are only forwarded by the kernel. It is just an interface between UI and debugger. Changes to the DAP message format will only affect the UI and not the kernels, making maintenance easier.

[JohanMabille]

Would not it be more in line with DAP to advertise it via capabilities of initialize request response? For example, "copy to clipboard" can be implemented relying on supportsClipboardContext?: boolean;.

I'm not sure. The idea until now was to extend the existing DAP by adding new messages, not by modifying the existing messages or types used to compose the messages. Adding new capabilities to the existing ones in the DAP would mean introducing a new interface (inheriting form the Capabilities one) and replacing the InitializeResponse spec with our own. From a protocol side, it is easier to maintain a clear separation between the DAP original specification, and our adds to it.

[JohanMabille]

Additional context on this: the copyToGlobals request was added to the Jupyter Debugger Protocol and implemented in xeus-python and ipykernel. However, this request:

• is not part of the Debug Adapter Protocol
• might be hard if not impossible to implement for some languages.

Therefore, a solution is to make it optional, like the richInspectVariables request, and avertise for its availabitily in the debugInfo request.

[fcollonval]

Thanks for this JEP @brichet

I would suggest describing in the JEP the request and response format of this new message; adding the section Reference-level explanation seems the right place for that.

[brichet]

Thanks for this JEP @brichet

I would suggest describing in the JEP the request and response format of this new message; adding the section Reference-level explanation seems the right place for that.

Thanks @fcollonval, I updated the description.

[ivanov]

I am abstaining from this vote as I have no familiarity with the debugger. I have never had occasion to use it as a user, let alone dive into its implementation details as a developer.

[gabalafou]

I wanted to familiarize myself more with this before voting, but realistically, I'm not going to find the time, so I'm abstaining.

[brichet]

Some additional information to summarize this feature:

When the debugger stop on a breakpoint, some variables are in the global scope and some other can be in a local scope (in a function). Using the debugger tools only does not help for some introspection in complexe variables.

When the execution ends, the variable(s) in the local scope will not be reachable anymore.

We added a feature in some python kernels (ipykernel and xeus-python, see #93 (comment)) to be able to copy a variable from a local scope to a global scope during a breakpoint. This way, the variable(s) can be introspected after the code execution, since it still exists in the global scope.

The aim of this JEP is only to send a flag to Jupyterlab (or other UI), whether this feature is supported or not by the kernel.

[JohanMabille]

6 yes, 3 abstains, 2 no votes, let's merge!