3 ms·

Crazy seeing this here! I searched for this last week, as I'm playing with building the same thing but as a VSCode extension.. See here [1] I found another si

Crazy seeing this here! I searched for this last week, as I'm playing with building the same thing but as a VSCode extension.. See here [1] I found another similar project on Github, but it was from many years ago. Yours did not turn up.. Very interested in finding out how you implemented it [1] https://github.com/micoloth/vscode-reactive-jupyter#readme https://github.com/micoloth/vscode-reactive-jupyter#readme

smacke 3y ago
We have a couple of papers that go into some of the details. https://smacke.net/papers/nbsafety.pdf https://smacke.net/papers/nbsafety.pdf https://smacke.net/papers/nbslicer.pdf https://smacke.net/papers/nbslicer.pdf It looks like you are using a static approach for dependency inference. There are a lot of benefits to static approaches, but they can only get you so far. My JupyterCon presentation includes a bunch of examples where dynamic approaches are a must: https://t.ly/78rS https://t.ly/78rS Besides that, there are a bunch of interesting design decisions about when to add edges between cells, when to break them, what metadata to annotate edges with, etc. I'm hoping to abstract a way a bunch of the complexity by developing something like a runtime version of a language server protocol (working name "language kernel protocol") so that any editor that implements the protocol would get reactivity for free when running a kernel that likewise implements the protocol. I have an early version of this which is how IPyflow works for both Jupyter and JupyterLab; VSCode would be a great editor to add support for next.