Consider scripting integration with the napari console

[gselzer]

In #265, @kephale added a widget that replicates the Script Interpreter in napari-imagej. However we noted on Zulip that ideally, we wouldn't need to add a second console - we could access all of the desired variables through the napari/napari-console plugin that currently exists.

I'm not sure whether this functionality is currently possible though, so I haven't implemented it yet.

[ctrueden]

Certainly it's possible. Here is the code from SciJava ScriptREPL:

bindings.put("ctx", context);
for (final Service service : context.getServiceIndex().getAll()) {
	final String name = serviceName(service);
	bindings.put(name, service);
}

which would just need to be Pythonified, replacing bindings with whatever dict the napari IPython REPL uses for globals:

ctx = napari_imagej.nij.ij.context()
services = {"ctx": ctx}
for (service in ctx.getServiceIndex().getAll()):
    name = service_name(service)
viewer.update_console(services)

which I guess you would do as soon as napari-imagej finishes initializing the ij...

Also need to port the serviceName function from ScriptREPL, which tries to be clever about giving each service a nice variable name.

I was unfortunately not able to fully test the above quickly, because:

 RuntimeError: napari-imagej requires the following component versions:
	org.scijava:scijava-common : 2.95.0 (Installed: 2.94.2)

which happens because I'm wrapping a local Fiji and it still ships with 2.94.2.

[gselzer]

Oh, I didn't see viewer.update_console (not sure how I missed it, it's the first function implemented 😆). That makes this issue a quick fix then (I'd hope)!

[ctrueden]

@kephale We are discussing whether to keep the dedicated SciJava REPL widget in napari-imagej, versus relying solely on the main napari console with SciJava services injected as globals/locals. Could you briefly comment on your motivating use case for adding the SciJava REPL in the first place? Would the napari console be sufficient if we expose all the services in an analogous way? Or is there some further reason we should keep the SciJava REPL as its own dedicated console in addition?

[kephale]

I found it to be a convenient way to interactively call into plugins and such. I would definitely want to have a SciJava Context, but sometimes I might want something like the SciviewService...

[ctrueden]

@kephale Indeed, that's what I mean by "expose all services in an analogous way". Populate the napari console's bindings the same way we do the SciJava REPL's, so the same code (modulo language syntax differences) would work. It sounds like if we do that, you'll get similar convenience, so that's the way we're currently leaning, in the interest of reducing the number of lines of code to maintain. But still open to the idea of leaving the dedicated SciJava REPL in there if there are things it brings to the table (e.g. scripting in languages besides Python; operating directly in Java land rather than on the Python side) that matter to you.