Don't link the variable viewer to just notebooks

[davidanthoff]

For the Julia extension we would only be able to adopt the new built in variable viewer if it also supported showing variables from active REPL processes and potentially down the road for test processes, i.e. the entire variable viewer ideally would not be linked to notebooks in any fundamental way.

Previous discussion at #166296 (comment)

UI example how this looks currently in Julia at #165445 (comment)

I think this affects both the API, i.e. ideally something like NotebookVariableProvider would just be called VariableProvider etc and the UI, where we would need at least one more top level layer in the tree for different processes for which variables can be shown.

This point here was already mentioned in various existing issues, but I thought it might make sense to have a separate issue to track this specifically.

[amunger]

Thanks for creating this.
One question I had for Julia's implementation - How are you communicating with the live julia process to gather the variable information? Is it using an established debug session or are you able to just use the same channel that the REPL is using.

Asking because another option would be to reuse the debugger variable view. I haven't fully investigated what that implementation would look like, but having a debug session would certainly lead more in that direction.

[davidanthoff]

We have a JSON-RPC connection between the REPL process and the extension and use custom messages over that for the variable viewer. That connection is also used for lots of other things. So, this is entirely independent of any debug session.

Users can start the debugger from the REPL, but those debug sessions are short, essentially one can prefix a REPL command with @run or @enter and then a debug session starts just for the execution of that one command. But these debug sessions are terminated as soon as the command has finished executing.

I kind of like the idea to unify things, but maybe one question there is that the debugger really only shows variables when execution is paused, right? With a REPL or a notebook we would need kind of additional "states" during which variables can be viewed, like "idle" or something...

[davidanthoff]

@amunger I just wanted to bump this, I'm seeing that the notebook variable viewer is getting more work, and we would love to adopt it for the Julia extension, but having it tied to notebooks is a blocker for us :)

[amunger]

I've brought this up with a few members of the team, and unfortunately, I don't think there is a good way to generalize this provider within the standards of vscode APIs. The provider needs to be attached to something concrete so that we know more about its lifetime, and when it is applicable.

Another option that might help here is that we are looking into a built-in REPL UI, and the current thinking is to handle the execution through something very similar to a notebook controller, which would make it pretty straight forward to allow for a variable provider.

But either way, I hope to eventually have a path forward for you.

[pfitzseb]

Could we attach the variable viewer to the kernel instead of the notebook? Said kernel would then back either a notebook or a REPL.