Add lite-command to run Lab/Lite commands from the terminal

[ianthomas23]

This is experimental code to support the running of JupyterLab/JupyterLite commands from the terminal. Here is a demonstration; note there is a lot of tab completion which is key to this being a good user experience:

lite-command.mp4

It is the first example of a cockle "ExternalCommand" (a TypeScript command running in the main UI thread) that uses the cockle Argument classes to give semi-automatic tab completion. The API for this has been changing a lot and I am not sure it is a particularly good API yet, and if/when this is merged it will bake-in the API in cockle.

This needs jupyterlite 0.7.0 so initially using the 0.7.0a7 pre-release.

The command name is called lite-command. I am experimenting with similar commands for accessing JupyterLite settings (lite-setting) and kernels (lite-kernel). I think it is sensible to keep them as separate commands registered in their own plugins so that they can be individually disabled. I think it is probably good to have them part of the terminal repo rather than in their own repo, but I could be persuaded otherwise. I am also not 100% sure about the command names yet.

Handling of non-string command arguments is not supported yet, and there will need to be some sanitisation of path names as you can filebrowser:open-path path months.txt but not ./months.txt.

cc @bollwyvl who first suggested this idea.

[github-actions]

View PR preview of docs and deployment on Read the Docs

[bollwyvl]

Neato!

The completion looks nice and responsive.

From a discoverabilty perspective, list could be extended to be more tabular and include more columns, as these would match what users (usually) see on declarative UI elements (menus, command palette, etc). Perhaps including the title by default, or having an explicit --show=id.

Naming things is certainly hard, and in the CLI, every keystroke counts, with a trade between laziness and readability. I could imagine the lite-* "namespace" being something that could be extended, with aliases and sensible defaults, with a lite wrapper that discovers subcommands...

lite-command
lite command
lite cmd
lite c # gets hairy down here, but some things are worth it

While the YAML-ish output is nice for reading, it seems like a lot of the stderr.write would benefit from an internal json representation, defaulting to actual yaml, with --json (and/or --jsonlines) output, and indeed, a way to feed JSON directly in was the best I came up with for jyg for non-simple arguments.

Another useful thing when running commands would be a way to pre-validate the args, e.g. --strict against the schema.

The bummer with command schema is outputs are not described, and indeed, many useful internal tools return hot DOM/widget handles.

Zooming out a bit: my long-ish con was wrapping all of this kind of behavior in namespaced, declarative state machines, which could provide TUI/GUI driven by the schema. At that point, one could start building and sharing really cool things, with well-described capability boundaries. While SCXML is the W3C standard for declarative state machines, it's... kinda bad. The best I've found is the xstate schema, but sadly the only first-party, non-js implementation for python, hasn't been touched in years. They have, however, been looking at larger orchestrations of multiple "actors" running machines in their workflow spec... but most of that is driven by their SaaS offering.