PS I’d originally started this post in, if not in an upbeat mood about JupyterLab, at least a moderately hopeful sense. Only one way to find out, I guess, so I’ll have to try it and see… 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? 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. 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…?Īnd there is a migration path, of a sort. I also note the extension calls on a tornado decorator at one point, and I thought JupyterLab was trying to dump that package? One of the most widely used of our custom extensions colour highlights notebook cells: 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). 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.
#Jupyterhub vs jupyterlab full
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).
for modules already in presentation, do they stay with classic notebook or do we try to migrate?.I think there are two sorts of decision that need to be made with a view to presentation: 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. uses in-house developed and off-the-shelf magics.uses in-house developed ipywdgets (via jp_proxy_widget).uses in-house devleoped classic notebook extensions.uses “official unofficial” off-the-shelf classic notebook extensions.
0 kommentar(er)
