'How to debug a JupyterDash app using VSCode?
This is going to be a self-answered post, but that only means that I've got an idea of a solution, and that I'm very eager to hear about more efficient and stable approaches to the challenge in question.
I would like to know how you can combine the powers of JupyterDash and VSCode in order to run a debugging process for an .ipynb file that involves all of the following steps:
stepping into code,
running code line by line,
inspecting variables,
setting breakpoints,
inspecting callbacks, and
interactively editing variables.
I believe I've tried every imaginable combination of:
- Step into code with
F10 Run > Start Debugging (F5)from the VSCode menuRun and Debug (ctrl+Shift+D)from the Jupyter Notebook menu- Inspecting variables through
JUPYTER:VARIABLESin the VSCode Debug Console
Still I don't feel I've found a work-flow that is 100% satisfactory when it comes to interactivity and stability. And perhaps this isn't the best approach at all? Suggestions that do not include JupyterDash are therefore more than welcome.`
System info:
Python 3.9.6
VScode 1.60.2
Plotly 5.1.0
JupyterDash 0.4.0
Solution 1:[1]
I'll base this suggestion on the code presented here to produce a basic dash app with an interactive figure and a dropdown that triggers a callback:
Part 1 & 2 - Stepping into code and running code line by line
By default for a an .ipynb file, F10 in VSCode will trigger Step into function and place a yellow arrow at the first line of a cell. You can then step through your code line by line by hitting F10 again.
Figure 1.1 - Stepping into code with F10
Part 3. inspecting variables
After stepping through df = px.data.tips(), you can find the variable under JUPYTER:VARIABLES in the Debug Console:
Figure 3.1 - Debug console and variables
You can also inspect the contents of df by clicking the icon highlighted above to Show variable in data viewer:
Figure 3.2 - Data viewer
Part 4 - Setting breakpoints
If you've got some data manipulation going on within a callback you can set a breakpoint inside the callback:
Figure 4.1 - Set breakpoint.
Part 5 - Inspecting callbacks
In order to make the process move on to that particular breakpoint, you can hit F5 or even trigger the callback through the Dash App that this code sample produces. For example by choosing aggsunset from the dropdown menu:
Figure 5.1 - Make a selection to trigger callback debugging
Now you should notice that nothing happens in the figure itself. And if you go back to VSCode you'll see that the debugging process has moved on to your breakpoint.
Figure 5.2 - Code halting a breakpoint after callback is triggered
As you can see, a new variable is defined withing the callback as df2 = df.copy(). Strange as it is though, now you can only see the local variables of the callback:
Figure 5.2 - Jupyter Variables while debugging
But one neat thing here is that you can inspect the input from the dropdown in your app, which is:
colorscale = 'agsunset'
What's even cooler is that every time you change your dropdown value and trigger the callback, the value is updated under JUPYTER:VARIABLES:
Section 6 - Interactively editing variables
Figure 6.1 - Changing variables while debugging callbacks
If you move on to the DEBUG CONSOLE tab, you can take a closer a look at df2 with df2.tail():
Figure 6.2 - Inspect new variables
And you can even add a new column with df2['new_var] = 1:
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 |










