Jupytext and Jupyterlab: cell mini-toolbars missing with Jupytext Notebook

[nthiery]

I have configured my local jupyterlab so that markdown files are opened as Jupytext notebooks:

... 
	"defaultViewers":
	{
	    "markdown": "Jupytext Notebook",
        }

which works great and is since today used intensively by our 300 students. That smoothed our migration from Jupyter to JupyterLab :-)

However I noticed that the notebook is missing the usual cell mini-toolbars:

Anyone else noticed this? Is there any difference between "Notebook" and "Jupytext notebook beyond load/save, and maybe some additional menus?

My local setup:

> mamba list | grep jupytext
jupyter                   1.0.0                    pypi_0    pypi
jupyter-console           6.4.4                    pypi_0    pypi
jupyter-lsp               1.5.1                    pypi_0    pypi
jupyter-server-mathjax    0.2.6              pyhc268e32_0    conda-forge
jupyter-server-ydoc       0.1.11                   pypi_0    pypi
jupyter-ydoc              0.1.17                   pypi_0    pypi
jupyter_client            7.3.5              pyhd8ed1ab_0    conda-forge
jupyter_core              4.11.1          py310hff52083_0    conda-forge
jupyter_server            1.18.1             pyhd8ed1ab_0    conda-forge
jupyterlab                4.0.0a27                 pypi_0    pypi
jupyterlab-code-formatter 1.3.8                    pypi_0    pypi
jupyterlab-language-pack-fr-fr 3.4.post4          pyhb354a33_0    conda-forge
jupyterlab-widgets        1.1.1                    pypi_0    pypi
jupyterlab_pygments       0.2.2              pyhd8ed1ab_0    conda-forge
jupyterlab_server         2.15.1             pyhd8ed1ab_0    conda-forge
jupytext                  1.14.0             pyheef035f_0    conda-forge

[nthiery]

Additional comments: if I open a markdown notebook from the file browser with Open As -> Notebook instead of Open As -> JupytextNotebook, then the toolbar is there. If the notebook is already opened in a tab upon starting JupyterLab, it's ok as well.

[nthiery]

Hi @mwouts,

Just attracting attention to this issue which is still up. Just as an additional data point: I have just tried using "Notebook" rather than "Jupytext Notebook" as default viewer, but that did not work (the file gets opened with the editor).

Thanks in advance!

[nthiery]

Hi @mwouts,

Bumping and adding one more piece of information: it's not only the cell toolbar that does not appear in Jupytext notebooks, but in fact any widget provided by an extension (e.g. the buttons for the deck, git, ... extensions in the main tool bar). Which is quite annoying for our students.

We studied this a bit further with @brichet. His explanations is that extensions register their widgets based on the Jupyter viewer. In this case for the Notebook viewer, but not for the Jupytext Notebook viewer.

Altogether, given that the Notebook viewer works well for jupytext notebooks with "Open With -> Notebook", is there a motivation nowadays for having a different notebook viewer type? Do you see why choosing "Notebook" as default viewer in the settings does not work?

Thanks in advance!

Cheers,

PS: fun fact: "Jupytext Notebook" is internationalized to "Jupyter Notebook" in French which does not help with the confusion :-)

[mwouts]

Hey @nthiery , thank you for the ping - sorry I am running a bit behind these days!

Yes I would also find it simpler if we could just have the Notebook viewer. I am not so sure of why we need a Jupytext Viewer. @mahendrapaipuri or @parmentelat do you have any idea why configuring the default viewer as Notebook does not work?

There might be some interesting inputs about that in earlier issues/PR too.

[mahendrapaipuri]

As @nthiery pointed out, extensions registered with Notebook factory might not work with Jupytext Notebook. It is due to the fact that Jupytext Notebook is a factory by itself and extensions normally are registered with vanilla Notebook factory. There is a similar issue in #1198. See this comment

If we dont use Jupytext Notebook, the notebook and Python files wont be paired automatically upon saving, right?! I am not a Jupytext user so I might be wrong.

[mwouts]

Thanks @mahendrapaipuri for the input! Saving the paired files is done by the context manager, which is independent of the editor.

I think we need to figure out why in the first place we had to recur to another factory. If I remember correctly it's because the default notebook viewer checks that a document is a notebook not only using the document "type", but also its extension (which had to be ipynb at that point).

Maybe we could consider a PR on the default viewer in jupyterlab to only use the document "type"?

The issue where the new factory was developed is this one: https://github.com/mwouts/jupytext/issues/803., and the factory was developed by @fcollonval .

[parmentelat]

the need for this dual factory thing is a mystery to me..

I wish the regular notebook factory could be used to open jupytext notebooks, just like the classic notebook was able to do at the very least this is very confusing to users to have to choose between both, no ? it's hard to see any benefit, and on my end too I see quite a few little drawbacks in any case I have also noticed that in some cases it is possible to open a jupytext file with the regular notebook and in other contexts it's not; no actual clue why..

-- another oddity: open a jupytext notebook in jlab - for simplicity let's assume this is the only tab; close the session; open it again, the notebook comes back open .. but with the Notebook factory double-click on the same file in the file browser, another tab opens on the same content - but with the jupytext notebook factory this time - confusing again.. lucky us, the contents of both tabs are kept in sync (c'est déjà ça..)

I kind of got used to it, but yes if that thorn could be removed from our foot it would be just great...

[nthiery]

Ah ah, I had noticed this "double opening" behavior, but had not made the connection with the use of two "different" viewers. It also happens if you launch jupyter lab with jupyter lab file.md. If you do it twice in a row, then file.md is opened twice.

Thanks @parmentelat for the connection :-)

[fcollonval]

PS: fun fact: "Jupytext Notebook" is internationalized to "Jupyter Notebook" in French which does not help with the confusion :-)

I fixed it - will be part of the next language packs release.

Of note, the translation is done using the crowdin collaborative web service: https://crowdin.com/project/jupyterlab Feel free to join if you find some mistakes or missing translation.

[fcollonval]

The main issue (related to the need of a factory) is due to the impossibility to add an existing file type (for example markdown file) to an existing factory (for example Notebook) because of the principle "don't mess up the code you don't own". But creating new file types allows to bind to existing factory and creating new factory allows to bind to existing file type. Hence the new factory allows to open markdown file as notebook.

@brichet does your analysis take into account that we are tricking the toolbar factory to use the 'Notebook' namespace: https://github.com/mwouts/jupytext/blob/1ef1dea7d1d63e418ecc093025510e7b941ade9c/jupyterlab/packages/jupyterlab-jupytext-extension/src/factory.ts#L48

[mahendrapaipuri]

@fcollonval Cheers for the info.

Looking into the sources, it seems like extensions are registered by name, which I guess the factory name. I did look into the docRegistry objects and the extensions seem to be tied to factories.

Do you have any elegant way in mind to solve this issue?

[nthiery]

Thanks @fcollonval for the feedback.

By the way: if this can help resolve this question, I on my side would be totally fine with using a specific extension such as .nb.md to distinguish markdown notebooks from plain markdown files.

[parmentelat]

on my side I am currently using exclusively *-nb.md and *-nb.py for jupytext notebooks I think I remember I had gone for *.nb.suffix at some point and moved to this scheme later on but I can't remember the actual reason (need another brain ;) however if that's a consensus I can move to .nb.suffix

[parmentelat]

because of the principle "don't mess up the code you don't own".

I am not quite sure to understand this one; the very notion of a plugin is to let other people extend some core functionality; how is this different ?

[fcollonval]

@mahendrapaipuri the proposed solution of defining a new file type based on a composed extension like .nb.md seems the best approach here. But I recall that there are some issues with such composed extensions handling in Jupyterlab. So don't hesitate to ping me with your finding if you give it a try.

because of the principle "don't mess up the code you don't own".

I am not quite sure to understand this one; the very notion of a plugin is to let other people extend some core functionality; how is this different ?

To explain my statement a bit more, a plugin is a foreign piece of Code owned by a third party that interacts with other code pieces it does not owned. The ownership is the key here as ownership allows the definition of the intent. However in the mentioned use case of using the notebook widget factory for the markdown file type that principle is not met by jupytext as it does not own neither of the two parts.