jupytext VS ipyflow

Jupytext (https://github.com/mwouts/jupytext) has been designed exactly for this

jupytext is your friend.

So if you run your own jupyter server, -jupy+text can be a great workflow : it takes your notebook synchronized with other formats (python file, makdown, ...), so you can edit your py/md file with neovim, and refresh the browser to execute the notebook.

Automatically convert ipynb files to py when saving them on JupyterLab

I don't use Jupyter so I don't know for sure, but on a quick glance you might want to look at https://github.com/mwouts/jupytext to see if that could help at all.

The format is only partially invented, it follows Jupytext [0], but adds support for cell metadata. There is no obvious way to get that in fenced codeblocks, especially with the ability to spread it over multiple lines so it plays well with version control.

One more consideration is that it's not "Markdown with code blocks interspersed", one might as well use plaintext or AsciiDoc.

Of course there are tradeoffs.. I wish I had more time to work on it.

[0]: https://github.com/gzuidhof/starboard-notebook/blob/master/d...

[1]: https://github.com/mwouts/jupytext

Using jupytext (allows you to open .md files as notebooks) + jupyter gives you pretty much the same experience. The main issue is that the cell's output will be discarded. To fix it, you can use ploomber to generate an output HTML, so the workflow goes like this:

First, the format. The ipynb format does not play nicely with git since it stores the cell's source code and output in the same file. But Jupyter has built-in mechanisms to allow other formats to look like notebooks. For example, here's a library that allows you to store notebooks on a postgres database (I know this isn't practical, but it's a great example). To give more practical advice, jupytext allows you to open .py files as notebooks. So you can develop interactively but in the backend, you're storing .py files.

You're probably referring to nbgather (https://github.com/microsoft/gather), which shipped with VSCode for a while.

nbgather used static slicing to get all the code necessary to reconstruct some cell. I actually worked with Andrew Head (original nbgather author) and Shreya Shankar to implement something similar in ipyflow (but with dynamic slicing and a not-as-nice interface): https://github.com/ipyflow/ipyflow?tab=readme-ov-file#state-...

I have no doubt something like this will make its way into marimo's roadmap at some point :)

Np.

From https://news.ycombinator.com/context?id=35887168 re: ipyflow I learned about ReactiveX for Python (RxPY) https://rxpy.readthedocs.io/en/latest/ .

https://github.com/ipyflow/ipyflow :

> IPyflow is a next-generation Python kernel for Jupyter and other notebook interfaces that tracks dataflow relationships between symbols and cells during a given interactive session, thereby making it easier to reason about notebook state.

FWIU e.g. panda3d does not have a react or rxpy-like API, but probably does have a component tree model?

https://news.ycombinator.com/item?id=38527552 :

>> It actually looks like pygame-web (pygbag) supports panda3d and harfang in WASM

> Harfang and panda3d do 3D with WebGL, but FWIU not yet agents in SSBO/VBO/GPUBuffer

> Another giveaway is the ratio of stars to watchers / forks. I remember one project with thousands of stars but only 10 users "watching" it. They went on to raise a sizable seed round too.

Not necessarily indicative of foul play. I have two projects like this (https://github.com/smacke/ffsubsync and https://github.com/ipyflow/ipyflow) and I attribute it to not having great developer documentation.

It's not in the highlights, but one of the things that excites me most is this: https://docs.python.org/dev/whatsnew/3.12.html#pep-669-low-i...

> PEP 669 defines a new API for profilers, debuggers, and other tools to monitor events in CPython. It covers a wide range of events, including calls, returns, lines, exceptions, jumps, and more. This means that you only pay for what you use, providing support for near-zero overhead debuggers and coverage tools. See sys.monitoring for details.

Low-overhead instrumentation opens up a whole bunch of interesting interactive use cases (i.e. Jupyter etc.), and as the author of one library that relies heavily on instrumentation (https://github.com/ipyflow/ipyflow), I'm very keen to explore the possibilities here.

You’re looking for reactive kernels: https://github.com/ipyflow/ipyflow