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.
#Jupyterlab desktop 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 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).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.has custom branding (the insitutional logo replaces the Jupyer Logo).If we move, a question arises as to the extent to which we try to preserve extended functionality and theming.Ĭurrently, our classic notebook environment: 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.
0 kommentar(er)
