Code sharing with VS Code Jupyter Notebook implementation

[davidanthoff]

We are getting closer and closer to finishing the native Jupyter Notebook support in VS Code for Julia (see here). When I started, I copied a few functions from IJulia.jl over, but as things progressed I ended up copying a fair bit of code and now there is probably too much code duplication.

Should we try to arrange this is a way that instead of the VS Code extension copying code we move the shared code into its own package, say JupyterCore.jl, that both IJulia.jl and the Julia extension for VS Code can use? Probably mostly a question for @stevengj, whether he would be on board with that. This is not super urgent, I think we could start out by shipping the extension with all the code duplication and then also clean this up down the road.

For background, the notebook implementation in VS Code will not use the kernelspec configuration that IJulia.jl installs nor the jupyter protocol. Instead, it will be a "no configuration" solution, i.e. if a user has the Jupyter and Julia extension for VS Code installed, everything will work without any further things. The whole execution aspect of things is handled by the native notebook execution API that VS Code started shipping recently. In the VS Code Julia extension we can't take a full dependency on IJulia.jl because we in general cannot take dependencies on packages that pull in anything binary (so in this case MbedTLS.jl and maybe Conda.jl), that wouldn't work with the way we deploy Julia packages in the extension.

[stevengj]

So their notebook API doesn't use ZMQ, but uses the same JSON message protocol over some other transport layer?

I'm fine with an IJuliaCore.jl package if that makes sense…

[davidanthoff]

VS Code now has a notebook API that is an in-process JavaScript API, like all the other APIs that VS Code provides. VS Code extensions can just directly interface with that, and the pending PR on the Julia extension does that. At that level we (the Julia extension) essentially tell VS Code that we can execute Julia code in notebooks and provide a callback that does so.

Inside the Julia extension we handle kernel startup and the communication between the Julia extension (written in TypeScript) and the Julia kernel. We are using a custom, internal JSON-RPC based protocoll for that that is based on the existing implementation we use for communication between the Julia REPL in VS Code and the Julia extension. One benefit of that design is that we can re-use all the features we've created for code execution in the REPL: the tree variable explorer, progress reporting, debugger etc. Another nice feature of this is that we can ship everything we need for this to work as part of the extension itself, and there is also no config state anywhere, so hopefully this will be a very robust solution that just always works.

MS is shipping a Jupyter extension for VS Code. That extension knows how to read and write Jupyter notebook files. It also knows how to interface with traditional Jupyter kernels via ZMQ via the normal kernel spec registration stuff. The design now is that the Jupyter extension will use traditional Jupyter ZMQ kernels when there is no language extension installed that provides a richer, more native execution experience. But if say the Julia extension is installed, then execution of code will be handled directly by the Julia extension, and all the additional features that such an extension might have (variable explorer, debugger, in our case progress reporting etc) will light up.

The kind of code that I would move into IJuliaCore.jl is stuff like the MIME type list, the whole console capture code, some of the display bundle creation code etc. Essentially the plumbing where we would want the same behavior of IJulia and the VS Code extension. But anything protocoll specific, setup specific etc. would stay in IJulia.jl because we don't need that in the extension, plus that seems the place where the binary dependencies come into play.

One big question at this point is whether a Julia kernel in VS Code should export an IJulia module... And if it does, we would probably have to try to make it API-compatible with what IJulia does. I'm not sure right now what the best thing to do there is, I think I need to take a more careful look next at what kind of things packages or notebooks do with the IJulia module.

I'll start with an IJuliaCore.jl package for now.