MyST-NB
MyST-NB copied to clipboard
Use of Cell ID for glue like functionality
Now that nbformat has implemented cell IDs as part of the notebook specification (see https://github.com/jupyter/nbformat/commit/9ede360590e26ef0118a86cfb27b614191821577 and the JEP https://jupyter.org/enhancement-proposals/62-cell-id/cell-id.html), in may be good to use these as the means to reference a cell for rendering outputs in a glue like manner (i.e. in a place not directly after the input cell)
Note, that in https://github.com/jupyterlab/jupyterlab/issues/9064 I have asked for clarification on how/if these IDs will be available within the jupyter lab/notebook interfaces.
I also plan to add round-trip access to these IDs in Markdown-to-Notebook conversions, within the code base and in jupytext's myst
format
I think this would be great - though I suspect there might be some benefits to supporting a user-given :name:
in addition to this. For example:
- Cell IDs are probably going to be less easily-readable by a human since they're auto-generated
- I suspect some users will create confusion due to creating new cells (with new IDs) and copying content into them
- For
myst-notebooks
, people will need to give their own:name:
to a cell in order to reference its output anyway, and I don't think we could use theid
field for this since it is auto-generated (but I might be wrong on this, depending on whether the UIs will allow for user-given cell IDs...I believe that JEP left it intentionally vague)
There's nothing in the JEP to say it has to be auto-generated and/or cannot be changed by the user
@chrisjsewell right - though this is why we should see what the UIs tend to do here. E.g., I think that Colab will auto-generate the IDs because it already does this so that cells are linkable. I'm not sure what JupyterLab / VSCode / etc will do. As long as those UIs won't clobber a pre-existing cell ID (e.g., if a myst-notebook
with multiple cells but only a single cell having an id
field will work without over-writing the manually-specified ID), and if they'll allow users to edit it themselves, then I think we should be fine using ID for this.
I think it goes against the concept of an id, for any programme to automatically override an existing id. As already mentioned, I'm not sure if they will be manually overridable, although nbformat does specifically ensure generated ids are "human-friendly"
I'm just saying that if other UIs do clobber the IDs, it's something we should know about and anticipate. E.g., look at a Colab link:
https://colab.research.google.com/notebooks/intro.ipynb#scrollTo=2fhs6GZ4qFMx
the scrollTo
I believe points to their version of a cell ID (they implemented it well before this JEP was published). I don't know if they plan to let users start bringing notebooks with their own IDs. Just saying it's something we need to be aware of.