Scoping Out JupyterLab Extensions

Over the years, we’ve added quite a few classic notebook extensions to the mix in the environment we distribute to students in our data management and analysis course.

One of the things that has put me off moving to JupyterLab has been the increased complexity in developing extensions, both in terms of the typescript source and the need to familiarise myself with the complex and bewildering JupyterLab framework API.

But if we are to move to JupyterLab components, or if I want to try to make more use of JupyterLite, we are going to need to find some JupyterLab extension equivalents to the extensions we currently use in classic notebooks; or find someone to create them. And on current form, given the chances of the latter are near zero, that means I need to update the extensions myself. So this post is a quick review of already available JupyterLab extensions that might serve as equivalents of the extensions we currently use, or that I could use as cribs for my own extensions.

“Official” cookie cutter and example extension repos are available: jupyterlab/extension-cookiecutter-ts, jupyterlab/extension-examples. The examples repos are filled with dozens and dozens of developer cruft files and it’s not clear which are actually required, of those that are required, whether they are/can be/should be automatically generated (and how), or whether not-essential files can break things if they are laying around and not correct etc etc. This is a confusing and a massive blocker to me trying to get started from a position of wanting to have as little to do as possible with formal developer IDEs, build crap, test crap, etc etc. Productivity tool support for “proper devs” in “proper IDEs” is all very well for “proper devs”; but for the rest of us, it’s a hostile “you’re not welcome” signal (think: hostile architecture) and goes very much against a minimum viable example principle where only the bare essentials are included in the repo…

I’m not sure what extension, if anything, is powering the cell tags, which appear to only be accessed via the settings gear in the right hand margin tab list:

If you click on a tag, it seems to disappear, which is a usability nightmare, in my opinion…

Collapsible_Headings: JupyterLab equivalent of classic notebook nbextensions/collapsible_headings extension; note that the value assigned to heading_collapsed metadata is *not* the same in the JupyterLab and classic extensions. In the classic extension, the assignment is to the boolean true; in the JupyterLab extension, the assignment is to the string "true". See this related issue requesting metadata parity across extensions.

jupyterlab-skip-traceback: JupyterLab version of classic notebook nbextensions/skip-traceback extension for collapising error messages beneath error message name header; dozens of files in the repo, no idea which are necessary and which are just stuff;

jupyterlab-system-monitor: “display system information (memory and cpu usage)”, a bit like the classic notebook jupyter-resource-usage (nbresuse as was?) extension;

jupyterlab-execute-time: display cell execution times, similar to classic notebook nbextensions/execute_time extension;

spellchecker: “highlight misspelled words in markdown cells within notebooks and in the text files”, cf. classic notebook nbextensions/spellchecker extension;

jupyterlab_code_formatter (docs): format one or more code cells; cf. classic notebook nbextensions/code_prettify extension;

jupyterlab-cell-flash: “show a flash effect when a cell is executed”; this could be a useful crib for replicating some of the cell run status indicators that are provided for the class notebook UI by nb_cell_execution_status (pending, running, completed cell activity).

clear-cell-outputs : what looks like a simple extension to clear all cell outputs from a toolbar; of the dozens of files in the repo, I’m not sure what the smallest subset you actually need to get this to build/install actually is. The demo shows outputs in an empty notebook being cleared, so I have no idea if it actually does anything. This might be useful as a crib for: adding a toolbar button; iterating through code cells; clearing cell output;

jupyter-scribe: “transforms Markdown cells into rich-text-editing cells, powered by ProseMirror”; cf. classic notebook jupyter-wysiwyg or livemdpreview extensions.

jlab-hide-code: very old (does it still work, even?) extension to provide two toolbar buttons to hide/unhide all code cells; cf. classic notebook nbextensions/hide_input_all extension;

jupyterlab-hide-code: provides a JupyterLab toolbar button “to run the code cells and then to hide the code cells”;

jupyterlab-show-cell-tags: show cell tags within notebook UI;

jupyterlab-codecellbtn: add a run button to the footer of each code cell;

jlab-enhanced-cell-toolbar: enhance cell toolbar with a toolbar for selected cells allowing cell type selection tool, code cell run button, tag display and tag editor tools;

jupyterlab-custom-css (about; not updated to JupyterLab 3.0?): add custom css rules in the settings in the Advanced Settings Editor;

visual-tags: “more easily choose which cells get executed”, apparently, but the README is just boilerplate cruft and I can’t see what this does (if anything), how to do it, etc etc.

jupyterlab_templates: create a new notebook from a notebook template.

There’s nothing I’ve found yet that provides anything like the nb_extension_empinken or nb_extension_tagstyler extensions for styling cells based on tags (if you know of an example, please suggest it via the comments).

There have been a couple of aborted(?)/stale-d attempts to add DOM attributes based on tags (eg here and as originally referenced here) but this enabling feature never seems to get enough traction to make it as a merged PR. There is also a community contributed celltag2dom, but it also looks like it may be unmaintained/stale (IIRC, I couldn’t make sense of the code, and as with many extensions built presimably from examples, there’s a stack of files and I have no idea which are necessary, what any of them do, if any of the essentially superfluous ones can break things if they are laying around but not right, etc etc.).

Author: Tony Hirst

I'm a Senior Lecturer at The Open University, with an interest in #opendata policy and practice, as well as general web tinkering...

%d bloggers like this: