Proposal: labgrid-client: interactive CLI prompt #1750
Description
Description and Rationale
The goal would be to have an interactive CLI prompt instead of just a shell CLI.
Benefits
shell agnostic auto completion
Instead of maintaining auto completion for different shells (as of now only bash is implemented) that might run out of sync with the actual CLI use the options we already added to argparse so they will never differ.
Also additional args could be completed such as resource names provided to the io command.
more discipline when releasing places
As of today we obesrved that places are not released by devs when they are done working.
We could either kick them or ask them to release the place - or reserve.
The first approach is effective but not very nice and might have undesired side effects.
The second approach might take a (unforeseeable long) while due to deviations in our devs circadian rythms - typical for our line of work.
When using a CLI prompt that acquires the place and releases it on SIGHUP it might work a litte better since it is more obvious that one is still on the hardware.
less latency
Especially when using jinja2 templates with loops each call to labgrid-client from the shell takes some time. So setting 3 GPIOs for example can take up to 20s.
While we could script this as well with strategies it's often more convenient to just do it by hand. This is even more true for devs that are not yet familiar with every aspect of labgrid.
more convenience -> more acceptance -> larger audience
Providing devs with more comfort might lead to more acceptance and in as such to a larger audience. Since not every one wants or has the capability to learn something completely new and they just want to make it work
Approach
The way I started implementing was hijacking argparse so prompt and shell behave the same.
Since argparse doesn't allow (at least not in a way I know of) to retrieve the args we put into it I wrote a wrapper that later gets comsumed by argparse and prompt_toolkit to build a completer
Outlook
We are going to develop this feature for internal use but it might be nice to have it upstream - for ease of pain when merging upstream into our fork.
I'm working on a POW right now - but before continuing further I would like to get your general opinion on that and maybe some input on other ways to implement it and to avoid redundant work.