bash-completion: cleanup and start introducing local uenv labels completion

[albestro]

DISCLAIMER: I'm not very proficient with bash, and it's my first time dealing with CLI11 and bash completion. Any suggestion is welcome! I opted for opening this PR as draft to start sharing a working (and hopefully evolving) experiment and get some early feedback on this.

I started this as an experiment (over #128 which immediately proved to be useful) to explore how bash completion can be extended for uenv, in particular targeting auto-completion for uenv images available locally (i.e. start and run).

Completion is a broad and complicated feature, and I'd like to keep this PR focused on "uenv labels completion for locally available images" as much as possible, while dealing with other extensions separately. However, current design is quite basic and some auxiliary reworkings might be needed to make this work.

TODO

• Extract bash completion script as "external" resource #128
• Distinguish positional arguments by name (e.g. image ls {uenv} is different from start {uenv}
• verify bash-completion requirement
• Explore how to deal with multiple uenvs (currently separated by comma)
• What local images should be suggested? image ls %ARCH?

[albestro]

I still believe that the best way forward is to keep this PR focused, as stated in PR first message

Completion is a broad and complicated feature, and I'd like to keep this PR focused on "uenv labels completion for locally available images" as much as possible, while dealing with other extensions separately.

So, trying to recap, IMHO the missing points/tasks for the targeted feature are:

1. SEMANTIC: use parameter name as driver for uenv completion
2. JUST ONE TIME: stop suggesting uenv if the parameter has been already chosen
3. MULTIPLE UENVs: start and run command allows to specify multiple uenvs (comma separated)
4. LISTING: currently it suggest just uenv for matching system, we might decide to just match the µarch

I listed them from higher to lower priority, and I'd say that for this PR:

• 1 one should just be a matter of consensus
• 2 one might be tricky and my require some more work (we can eventually consider it good enough for now, and delay it for future PRs)
• 3 & 4 can be considered future extensions (or topic for a broader discussion)

I'll write here some of the ideas, just to contextualize a bit more. I might eventually move this message/thread to a dedicated issue, depending on the evolution of this PR.

1. SEMANTIC

The basic idea is that a uenv label is accepted if the option added in cli has a specific name. Currently there is no homogeneity in naming, so this is the list of commands where a uenv might be specified

command	type	note
start	repo(1:N)
run	repo(1:N)
pull	registry
ls	search term
inspect	repo(1)
find	search term
delete	registry
add	repo(1)	label first, uenv second
rm	repo(1)

I see the next categories

• repo(1), repo(1:N): uenvs available in the repo, the difference is just arity (in case of 1:N see point 3)
• registry: these commands accepts uenv from the registry (possibly with namespace, e.g. build::)
• search term: this is just an expression for filtering

In this PR we aim at just the first category, in particular repo(1) (which can erroneously be suggested more times, see point 2). Moreover, for repo category in general, mount point completion is not taken into account.

The point here is that I'm proposing to reflect the option category in the parameter name (names are just indicative, they are just a starting point to give an idea):

• uenv: for repo(1)
• uenvs for repo(1:N)
• uenv-upstream for registry
• uenv-search-term for search-term

2. JUST ONE TIME

I should find a way to detect when a uenv label has been already specified/completed on the command line, so that the completion stop suggesting it.

At the moment the only two things I was able to think of are:

• evaluate the positional index
• use some form of regex to detect if such a parameter

The latter sounds like an over-complication to me (and not exactly straightforward considering all the variants). But also the first one is not so easy at the moment. Indeed, we can filter subcommands and flags, but how to filter values for flags?

For instance with uenv start myuenv, by filtering commands/subcommands/flags we can easily say that myuenv is the first positional. But what if we have uenv start --view default myuenv? in this case the filtered words become [default, myuenv], because the trivial "filter" (namely skip command and whatever words starting with -) is not able to distinguish between a positional argument and the value of a non-positional one.

Any idea? We can eventually decide that this is not so nice but we can live with that while we think for a solution.

3. MULTIPLE UENVs

Some commands, specifically start and run, accepts a comma separated list of uenvs. This might be not that difficult, but I would leave it as future exercise considering its priority.

4. LISTING

What list should the command use for suggestions?

• just the uenv images available in the repo matching the @system?
• or more generally whatever it is available for matching %uarch?

This might have an answer at an higher level.

[bcumming]

This looks good.

It is a big improvement over the current status quo. A more complete solution would require a non-trivial restructuring of the completion tooling - specifically we would have to add a callback to the uenv CLI that can generate completions.

So let's go with this solution while we work on the ultimate solution.