Kernel actions hooks

[fcollonval]

Problem

The current implementation of the debugger is agnostic to the notebook (or any document). It is only linked to the kernel that holds the debugger state. This raises some questions on how to customize kernel actions triggered by other extensions (in particular the notebook):

• The notebook toolbar buttons ▶️ and ⏹️ are behaving surprisingly when debugging as they do not result in Continue and Stop debugging; that is usually expected by those symbols when debugging (and this is implemented by those icon buttons in the debugger panel - so the UI is misleading the users same icons, different behaviors).
• In Implemented Restart and debug #10462 the need to get notice prior to sending the kernel restart request is bringing trouble to hook the feature in the existing commands Restart Kernel and ....

In the first case, the normal actions in the toolbar should ideally be changed to carry the debugger actions instead.
In the second case, callbacks executed before and after the actual action to carry out would allow to bring a better user experience.

Proposed Solution

Two solutions are envisaged:

• 👎 Create an API to allow synchronous callbacks to be registered after and/or before a command is executed.
• 👍 Create an API to allow synchronous callbacks to be registered in more dedicated place to deal only with kernel request.

For the before callback, a boolean would be returned. If false, the normal action won't be carried out.

The first solution is seen as less appropriate as it will open the path to anarchy with extensions adding multiple callbacks that results in non deterministic interactions. The second is seen as better as it narrows the changes scope. Unfortunately there is not a single place of kernel request channel but two: restart, interrupt,... actions are sent using the REST API when run cell is done by sending comm message.

A refinement of the second solution could be to allow for callbacks to be registered on the kernel REST API and to add a new kernel state when a debug session is in place (like kernel status break). That new status will be considered similarly by the non-debug actions as refusing any comm message.

cc @JohanMabille

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/detect-kernel-restart-inside-extension/8970/3

[fcollonval]

The pattern we used for the "copy shareable link" command in the file browser's context menu was to create a small targeted plugin that adds just that one command (this pattern could be used for a logical grouping of commands) and to have extension authors replace that extension with their own if they need: https://github.com/jupyterlab/jupyterlab/blob/master/packages/filebrowser-extension/src/index.ts#L446-L495

The downside of this approach is that it requires disabling an extension explicitly. But we could instead have that extension expose the disposable object that addCommand(...) returns so that an extension could both know if those commands have already been disposed (i.e. isDisposed) and if they still exist, the author could dispose them and add replacements? We'd have to think through the API a little bit, but it does seem like some of the notebook actions are logical extension points.

Another pattern that came out of conversation with @SylvainCorlay is to have a meta command that makes a decision about whether to use the default command or a debugger version of the command, potentially by always running the debugger version of the command and expecting some return value e.g., true or false to decide whether to short-circuit or to continue and use the default command.

Originally posted by @afshin in #10462 (comment)