Add debugger variable renderer based on mime type

[fcollonval]

Status :

Waiting on #10406 to ensure no visual regression
i won't have time to address #10406. This can be merged if approved.

References

Xeus-python is providing a new debug message to get a rich variable representation:
jupyter-xeus/xeus-python#446

Fixes #9867

This adds a command and a panel to display such rich variable.

Code changes

• Add a new command to trigger the variable rich display
• Add context menu on variable explorer
  • That required to add an interface on the explorer to get the selected variable
• In the tree view an action button is displayed on hover to render the variable
• Add some styling to make the error message in MainAreaWidget appear on error background.
• the kernel capability is returned in the debugInfo request to add this feature or not.

User-facing changes

New context menu on the variable explorer. It has one entry on the tree view to render the variable based on mime type information. And on the grid view it has a second entry to inspect the object

The rich renderer can also be triggered from an action button displayed on hover in the tree view.

Backwards-incompatible changes

N/A

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[jtpio]

Thanks!

Mind adding a quick screencast or screenshot to the description to have a quick idea of what it looks like??

[fcollonval]

Here comes the demo:

[jtpio]

Nice, thanks for sharing!

[krassowski]

This looks wonderful! One design point: the context menus are not greatly discoverable. Would it be a good idea to add a button on the listing to expose this feature more? For example, RStudio has small icons on the right-hand side of the variable explorer:

Edit: to clarify I did run the binder when this PR was originally opened and could not find a way to display the preview so gave up (I did not have time to look at the code first); if seasoned users cannot find it, newbies won't either.

[jtpio]

Looks like it also needs a lint pass: https://github.com/jupyterlab/jupyterlab/pull/10299/checks?check_run_id=2717509547

[fcollonval]

Code is linted and I added a button to display the rich view:

[krassowski]

How can we test this? Does it need a new version of xeus or some other component? Binder gives me:

Error: Unable to create message from dict: {'seq': 11, 'type': 'request', 'command': 'richInspectVariables', 'arguments': {'variableName': 'test', 'variablesReference': 0}}. richInspectVariables not in ['attach', 'breakpointLocations', 'cancel', 'completions', 'configurationDone', 'continue', 'dataBreakpointInfo', 'disassemble', 'disconnect', 'evaluate', 'exceptionInfo', 'goto', 'gotoTargets', 'initialize', 'launch', 'loadedSources', 'modules', 'next', 'pause', 'pydevdAuthorize', 'pydevdSystemInfo', 'readMemory', 'restart', 'restartFrame', 'reverseContinue', 'runInTerminal', 'scopes', 'setBreakpoints', 'setDataBreakpoints', 'setDebuggerProperty', 'setExceptionBreakpoints', 'setExpression', 'setFunctionBreakpoints', 'setInstructionBreakpoints', 'setPydevdSourceMap', 'setVariable', 'source', 'stackTrace', 'stepBack', 'stepIn', 'stepInTargets', 'stepOut', 'terminate', 'terminateThreads', 'threads', 'variables']

[SylvainCorlay]

How can we test this? Does it need a new version of xeus or some other component? Binder gives me:

It requires xeus-python master, but it is basically a chicken and egg situation. I presume it is safe to release xeus-python with this when this gets merged.

[jtpio]

[x] How to know the kernel as that feature? => proposal to return the kernel capability in the debugInfo request.

Is there a link to that proposal? Or maybe a work-in progress PR adding it to xeus-python?

[jtpio]

For now this is what it looks like on Binder if the kernel does not support the feature:

rich-inspect-variable-binder.mp4

[jtpio]

The debug message is called richInspectVariables, should the public method on the service named the same (in singular form)?

Not strong opinion, just raising the question before this gets in the pubic IDebugger API.

[fcollonval]

the kernel does not support the feature:

Thanks for testing @jtpio

I swiched the PR to draft as indeed it does not make much sense without having a feedback from the kernel to know if the feature is supported or not => waiting on @JohanMabille for that part.

The debug message is called richInspectVariables, should the public method on the service named the same (in singular form)?

Actually this is not the case for some other messages

method	request
inspectVariables	variables
displayDefinedVariables	inspectVariables

I switches the word because I like the convention of starting a method with a verb. But as it is not listed in the project style guidelines, I'm fine switch to your proposal.

Side note: the example highlights an unfortunate choice of words as a method and a request have the same name without being related.

[jtpio]

Side note: the example highlights an unfortunate choice of words as a method and a request have the same name without being related.

Right, the inspectVariables request was added after (for 3.1). Maybe there will be an opportunity to clean this up for 4.0 if this changes the API of the IDebugger service.

[JohanMabille]

xeus-python 0.12.5 has been released. It has full support for the richInspectVariables request.
Notice the additional field richRendering in the debug_info_response message. This field is optional (for backward compatibility) and should be tested since the support for richInspectVariable request has not been implemented in ipykernel yet.

[jtpio]

Thanks @fcollonval.

Just tried on Binder and the following code snippet:

from ipywidgets import IntSlider

slider = IntSlider()
slider

Gives the following behavior:

rich-variable-not-supported.mp4

This is with xeus-python 0.12.5:

[fcollonval]

Thanks for testing. I'm confused because this works with the same version on my machine 😕

[fcollonval]

Would it be that you are using the stable ipywidgets library? It works only with the upcoming version v8 for widgets.

[jtpio]

Would it be that you are using the stable ipywidgets library? It works only with the upcoming version v8 for widgets.

Yes it was with the latest stable ipywidgets 7.6.4. Works well with the latest prerelease 👍

I guess it would be fine to ship it before ipywidgets 8.0 is out. It will not be optimal to ipywidgets 7 users, but will work for other mime types.

[jtpio]

Let's tag as api-change since there are a couple of signature changes in the public interfaces.

[jtpio]

@goanpeca do we want to get this in the 3.2 release? Looks like the PR is listed in #10726

If so the comment above about the API change might be relevant?

[jtpio]

Looks great, thanks!

[jtpio]

If so the comment above about the API change might be relevant?

In that case we might have to bump to the 4.0 milestone.

[fcollonval]

I think we can bump to 4.0 as the lifecycle of the panels need improvements for it to be really useful - the current behavior close the panel each time the notebook changes.

[jtpio]

OK switching to 4.0 then.

[blink1073]

Thank you!

[meeseeksmachine]

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

https://discourse.jupyter.org/t/how-to-use-debugger-in-jupyterlab/11275/14

[fcollonval]

@meeseeksdev please backport to 3.3.x

[lumberbot-app]

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

git checkout 3.3.x
git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

git cherry-pick -m1 b98301c28da54acdc1360df37c9f8945dd0a6d5a

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

git commit -am 'Backport PR #10299: Add debugger variable renderer based on mime type'

4. Push to a named branch:

git push YOURFORK 3.3.x:auto-backport-of-pr-10299-on-3.3.x

5. Create a PR against branch 3.3.x, I would have named this PR:

"Backport PR #10299 on branch 3.3.x (Add debugger variable renderer based on mime type)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the Still Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free to suggest an improvement.