With the deprecation of classic notebook, and future notebook releases to be based on JupyterLab UI components, we’ll have to make a decision somewhen soon about whether to pin the notebook version in the environment we release to students in September starts modules to <7, move to RetroLab/new notebook, or move to JupyterLab. Or go somewhere else.
If we move, a question arises as to the extent to which we try to preserve extended functionality and theming.
Currently, our classic notebook environment:
- has custom branding (the insitutional logo replaces the Jupyer Logo);
- uses “official unofficial” off-the-shelf classic notebook extensions;
- uses in-house devleoped classic notebook extensions;
- uses in-house developed ipywdgets (via
jp_proxy_widget); - uses in-house developed and off-the-shelf magics.
In a move to JupyterLab UIs, the magics (MUST HAVE) should continue to work; the jp_proxy_widget applications (MUST HAVE) should work as long as that package continues to work; the branding should be fixable (SHOULD HAVE) (I was going to sy “how hard can it be?” to replace a logo, but I guess this is JupyterLab, so maybe REALLY HARD?!;-) , the off-the-shelf extensions (SHOULD HAVE tending to MUST HAVE) may get ported or may already have JupyterLab equivalents (see, for example, Scoping Out JupyterLab Extensions); and the custom notebook extensions (at the end of the day, these are [rpbably strictly SHOULD HAVE rather than than MUST HAVE, becuase materials are intended to degrade gracefully without them, but they are part of our value add and student experience proposition so it would be nice to keep them) will not (at least, not by me) get ported.
So what are we to do?
I think there are two sorts of decision that need to be made with a view to presentation:
- for modules already in presentation, do they stay with classic notebook or do we try to migrate?
- for modules in production, which environment do they develop notebooks for? Options are: classic notebook (I think this would be foolish); new notebook / JupyterLab (sensible option if the Jupyter environment is adopted); alternative environment (for example, VS Code, RStudio, Quarto, other). When it comes to alternatives, I think there should also be a consideration of more radical alternatives where the full notebook mechanic may not necessarily be required; Jupyter Book with ThebeLab, for example, if some way can be found to support persisting code edits (eg to browser storage).
I also think we should take the opportunity to explore alternative authoring and editing environments, as well as quality process automation (for example, Using Automation To Support Quality Assured Jupyter Notebook Publishing Processes): I tend to move between classic notebook, RStudio and VS Code, and if/when a standalone Quarto editor is made available, I’ll probably also try that for certain side-projects. Others might prefer things like Quarto, which is a bit more word-processor hand-holdy (see, for example, Previewing Richly Formatted Jupyter Book Style Content Authored Using MyST-md).
One of the most widely used of our custom extensions colour highlights notebook cells:
Poking around, it seems that there is a JupyterLab extension that allows you to set cell CSS style via metadata: educational-technology-collective/etc_jupyterlab_cell_properties. This looks ridiculously complicated to me, (maybe it needs an architecture statement?!), and seems to require a server extension among other things… (What is it that I keep saying about JupyterHub providing a really hostile architecture to have-a-go end user developers?!).
This makes me a little concerned: will the extension support cell highlighint in RetroLab? (Part of the promise of RetroLab for me was that it shared similar underpinnings to JupyterLab, but does that extend to “server companion” elements? And HTML / CSS structure?) Will the extension even run in JupyterLab in JupyterLite?
Whatever. I shall try to remain positive… When run in MyBinder, for the source repo at least (though I note, that uses an old version of JupyterLab?). it seems to work (though I note the JupyterLab metadata editor is really shonky – sometimes it lets you save, sometimes it doesn’t…?).
I also note the extension calls on a tornado decorator at one point, and I thought JupyterLab was trying to dump that package?
It would be more convenient if you could create a cell tag and then associate custom styling with it (I don’t know if / how Jupyterlab extensions have a simple configurator panel set-up like the classic jupyter_nbextensions_configurator?) but it sort of provides a workflow…?
And there is a migration path, of a sort. Our current notebooks use cell tags to identify cells for styling, so it would be easy enough to create a simple notebook processor that would check each cell for styling tags, and then add styling metadata to a cell as appropriate. Hugely inefficient and horrible (it would be so much easier if a cell tag could propagate into the UI DOM at an appropriate level, then to be styled via a custom CSS stylesheet, perhaps set via a cell styletags configurator) but workable as a workaround?
Only one way to find out, I guess, so I’ll have to try it and see…
PS I’d originally started this post in, if not in an upbeat mood about JupyterLab, at least a moderately hopeful sense. The jupyterlab-myst extension offers the promise of previewing various bits of MyST enhanced syntax in JupyterLab notebooks (though I haven’t tried or seen the extension working in RetroLab or JupyterLab in JupyterLite…), as briefly reviewed in the previous post, and the educational-technology-collective/etc_jupyterlab_cell_properties extension looked like it could be used in a hacky way to render style retwritten into cell metadata based on tags in my original notebooks.
But on reflection, I find myself falling back to my original position: that JupyterLab is not fit for our (which is to say, my!;-) purposes of long term availability (at least, when it comes to extensions that keep wroking) and support of easy end-user innovation. For a start, it’s too complicated. The cell properties extension does seem to work with an old build of JupyterLab, and if it still works with recent builds, how long is that likely to continue, particulalry given the extension also seems to require some sort of service level hacking? The repo does not appear to be maintained, and given the apparent complexity of it (I am not a dedveloper; I don’t have a clue how either JupyterLab, or typescript, or the build process works etc etc), we’re f****d if it breaks and I’m supposed to fix it (and we need things to keep working for years). I have no idea the extension works in RetroLab, or JupyterLite environments, or what would be involved to make it work if it doesn’t (or is it a bespoke JupyterLab desktop server solution). A comment I made in an issue to the jupyterlab-myst repo on leveraging cell tags in display fills me with no hope that there is an easy way to leverage cell tag data or cell metadata. If I recall correctly, cell tags were quite late to the notebook party, so it may be that architectural decisions were made early on that make it difficult for cell content processors to exploit cell metadata / cell tags from the notebook file, or the surrounding presentation layer (HTML DOM, CSS elements, etc.). I have no idea; if it is easy, I’m surprised I haven’t stumbled across some easy-to-follow demos around that that I would have tried to co-opt for my own purposes? From the cell properties extension, which appears to require mucking about with a server extension, it does look like it is not-just-for-me complicated!
Every time I try to show willing and get started with JupyterLab, it just seems to push me further and further away.
OUseful.Info, the blog... 