A book publishing project interested in extending jupytext code

Hey there @mwouts - I wanted to introduce myself and a team that I am working with.

We are a group of academic researchers who are working on a tech stack to build open, reproducible documents with Python. We’ve set up a GitHub organization to host the projects that we’re working on as a part of this project: https://github.com/ExecutableBookProject.

To better equip ourselves and the community in writing complex documents, we are also building a new markup text format, called myst :- https://github.com/ExecutableBookProject/myst , that basically tries to combine the extensibility and strong semantic markup properties of reStructuredText with some features of Markdown.

Now, to do a seamless conversion between myst and ipynb, we thought of extending your amazing tool to include myst format. And before we write any code, it would be great if you can give us any heads up or ideas/suggestions on doing this properly.

Thanks again for this great project!

[mwouts]

Note that actually, I would be interested in going one step closer to real realtime updating. For me, the difference with the current behavior would be the following:

• when the user edits the md file on disk, the notebook is updated automatically, without having to reload it.
• the outputs are preserved in the browser, not in an (optional) ipynb file. Thanks to this a) sync is faster since we never read the ipynb file on disk for this realtime sync - only the text files, which are way lighter b) if the notebook is md only, we don’t lose the outputs when the notebook is updated (currently, when you reload a md only notebook, outputs are lost)

This real realtime sync is being discussed at #406, and will require a good understanding of the JS/TS part of Jupyter, together with a port of the combine_inputs_with_outputs function to these languages.

[mwouts]

By the way, I realise that, if you already have a two way converter myst <-> ipynb, you can plug it directly into the jupytext.reads/writes functions. An example of this is the pandoc format, for which we simply call pandoc:

https://github.com/mwouts/jupytext/blob/dbc6012d35a93d74ca915cc17365ebda139f3022/jupytext/jupytext.py#L54-L55

If you decide to take that route, you may

• add your converter as an optional dependency to Jupytext
• add an if self.fmt.get('format_name') == 'myst': in both jupytext.reads and jupytext.writes
• declare the myst format in formats.py (and import the myst format version number from your package)
• and activate the round trip tests for the new myst format, as discussed above.

This will provide the same functionality (i.e. support of myst on the command line and in the contents manager), and may be easier to develop or maintain.