A visual debugger for Jupyter
Most of the progress made in software projects comes from incrementalism. The ability to quickly see the outcome of an execution and iterate has been one of the main reasons for the success of Jupyter, especially in scientific exploratory workflows.
Jupyter users like to experiment in the notebook, and to use the notebook as an interactive communication tool. However, for more classical software development tasks such as the refactoring of a large codebase, they often switch to general-purpose IDEs.
The Jupyter project has made strides in the past few years towards filling that gap, notably with the JupyterLab project, which enables a richer UI including a file browser, text editors, consoles, notebooks, and a rich layout system.
However, a missing piece (which has remained one of the main reasons for users to switch to a different tool) is a visual debugger. This feature has long been requested by users, especially those accustomed to general-purpose development environments.
A debugger for Jupyter
Today, after several months of development, we are glad to announce the first public release of the Jupyter visual debugger!
This is just the first release, but we can already set breakpoints in notebook cells and source files, inspect variables, navigate the call stack and more.
Try the debugger on binder
You can also try the debugger online with binder. Just click on the binder link:
Installation
- The debugger front-end can be installed as a JupyterLab extension.
jupyter labextension install @jupyterlab/debugger
The debugger front-end will be included in JupyterLab by default in a future release.
- In the back-end, a kernel implementing the Jupyter Debug Protocol (which will be detailed in the next section) is required. The only kernel implementing this protocol, for now, is
xeus-pythona new Jupyter kernel for the Python programming language. (Support for the debugger protocol in ipykernel is also on the roadmap).
conda install xeus-python -c conda-forge
Once xeus-python and the debugger extension are installed, you should be all set to use the Jupyter visual debugger!
Note: Depending on the platform, PyPI wheels are available for xeus-python, but they are still experimental.
The Jupyter Debug Protocol
New message types for the Control and IOPub channels
Jupyter kernels (the part of the infrastructure that executes the user's code) communicate with the rest of the infrastructure with a well-specified inter-process communication protocol.
Several communication channels exist, such as
- the Shell channel, which is a request/reply channel for e.g. execution requests
- the IOPub channel, which is a one-directional communication channel from the kernel to the client, and is used e.g. to forward the content of the standard output streams (stdout and stderr).
The Control channel is similar to Shell but operates on a separate socket so that messages are not queued behind execution requests, and have a higher priority. Control was already used for Interrupt and Shutdown requests, and we decided to use the same channel for the commands sent to the debugger.
Two message types were added to the protocol:
- the
debug_[request/reply]to request specific actions to be performed by the debugger such as adding a breakpoint or stepping into a code, which is sent to the Control channel. - the
debug_eventuni-directional message used by debugging kernels to send debugging events to the front-end. Debug events are sent over the IOPub channel.
Extending the Debug Adapter Protocol
A key principle to the Jupyter design is the agnosticism to the programming language. It is important for the Jupyter debug protocol to be adaptable to other kernel implementations.
A popular standard for debugging is Microsoft's "Debug Adapter Protocol" (DAP) which is a JSON-based protocol underlying the debugger of Visual Studio Code and for which there already exist multiple language back-ends.
It was therefore natural for us to use the DAP messages over the debug_[request/reply] and debug_event messages that we just added.
However, it was not quite sufficient in the case of Jupyter. Indeed
- In order to support page reloading, or a client connecting at a later stage, Jupyter kernels must store the state of the debugger (breakpoints, whether the debugger is currently stopped). The front-end can request that state over with a
debug_requestmessage. - In order to support the debugging of notebook cells and of Jupyter consoles, which are not based on source files, we also needed messages to submit code to the debugger to which breakpoints can be added.
Besides these two differences, the content of the debug requests and replies corresponds to the debug adapter protocol.
All these extensions to the Jupyter kernel protocol have been proposed for inclusion in the official specification. The JEP (Jupyter Enhancement Proposal) can be found here.
Xeus-python, the first Jupyter Kernel to support debugging
Xeus is a C++ implementation of the Jupyter kernel protocol. It is not a kernel by itself but a library that helps kernel authoring. Xeus is useful when developing a kernel for a language that has a C or a C++API (like Python, Lua, or SQL). It takes the cumbersome task of implementing the Jupyter messaging protocol for the kernel author to focus on the core interpreter tasks: executing code, inspecting, etc.
Several kernels have been developed with xeus, including the popular xeus-cling kernel for the C++ programming language, based on the cling C++ interpreter from CERN. The xeus-python kernel is an alternative Python kernel to ipykernel, based on xeus. The first release of the xeus-python kernel was announced on this blog earlier this year: https://blog.jupyter.org/a-new-python-kernel-for-jupyter-fcdf211e30a8
Xeus-python was an appropriate choice for this first implementation of the debugging protocol because
- it has a pluggable concurrency model, which allowed running the processing of the Control channel in a different thread.
- it has a lighter-weight codebase which made it a convenient sandbox to iterate upon. Implementing the first version of the protocol in ipykernel would have required more significant refactoring and consensus building at an early stage.
The roadmap of Xeus-python
The short-term roadmap for xeus-python includes
- adding support for IPython magics in xeus-python, which is the main missing feature with respect to ipykernel.
- improving the PyPI wheels of xeus-python.
What about other kernels?
The work in the front-end is valid for any kernel implementing the extended kernel protocol.
We will be working in 2020 to enable debugging with as many kernels as possible.
This will soon be the case for other xeus-based kernels which share a large part of the implementation with xeus-python, such as xeus-cling.
Diving into the debugger front-end architecture
The debugger extension for JupyterLab provides what users would typically expect from an IDE:
- a sidebar with a variable explorer, a list of breakpoints, a source preview and the possibility to navigate the call stack
- the ability to set breakpoints directly next to the code, namely in code cells and code consoles
- visual markers to indicate where the current execution has stopped
When working with Jupyter notebooks, the state of the execution is kept in the kernel. But a cell can be executed and then deleted from the notebook. What should happen when a user wants to step in deleted code?
The extension supports that particular use case and enables retrieving a read-only view of the previously executed cell.
Consoles and files also have support for debugging.
Debugging can be enabled on a notebook level, which lets users debug a notebook and work on a different one at the same time.
Variables can be inspected using a tree viewer and a table viewer:
The debugger extension for JupyterLab has been designed to work with any kernel that supports debugging.
By relying on the Debug Adapter Protocol, the debugger extension abstracts away language-specific features and provides a consistent debugging interface to the user.
The following diagram shows how the debug messages flow between the user, the JupyterLab extension and the kernel during a debugging session.
Future developments
In 2020, we plan on making major improvements to the debugger experience:
- Support for rich mime type rendering in the variable explorer.
- Support for conditional breakpoints in the UI.
- General improvements of the debugger user experience.
- Enable the debugging of Voilà dashboards, from the JupyterLab Voilà preview extension.
Acknowledgements
The JupyterLab debugger is the result of the collaboration and coordination of developers from several institutions, including QuantStack, Two Sigma, and Bloomberg.
About the developers
Jeremy Tuloup is a Scientific Software developer at QuantStack. He authored a large part of the front-end of the JupyterLab debugger.
.
.
.
Borys Palka is a software developer at Codete. He authored a large part of the front-end of the JupyterLab debugger.
.
.
.
Johan Mabille is a scientific software developer at QuantStack. Johan is a co-author of xeus, and developed the debugger extension to xeus-python. He also authored a large part of the debugger front-end.
.
Martin Renou is a scientific software developer at QuantStack. He is the original author of xeus-python, the xeus-based Python kernel, and contributed to the new concurrency model used for the debugger.
Afshin Darian is a software developer at Two Sigma, and one of the authors of JupyterLab.
.
.
.
.
Sylvain Corlay is the founder and CEO of QuantStack, and a core Jupyter developer. He co-authored xeus and xeus-python.
from Hacker News https://ift.tt/2Jf6wQy
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.