What's the best structure for the qlever control script?

[hannahbast]

@bradenmacdonald @Goblin80 @Qup42 @joka921 @LorenzBuehmann @lehmann-4178656ch @patrickbr

As the Python version of the qlever script becomes more mature, I am wondering about the best command structure. I see two general approaches:

1. Right now, the script supports chains of commands (called "actions"), for example: qlever get-data index start. Options can be set via a config file (called Qleverfile) or via the command line, for example qlever server.PORT=1234 start. Currently, these options can appear anywhere in the sequence and are activated at exactly the point where they appear, but that is a detail.

2. Having such sequences looks nice and easy, but it's not very common for other command-line tools. For example, git and docker have a single-command structure with options, for example git add --update or git commit. If you want to chain actions, you can define your own alias in the .gitconfig in your home directory, for example [alias] ac = !git add --update && git commit.

Which of the two approaches should we take?

[Goblin80]

Arguments for the first approach:

qlever --get-data --index --start or qlever -gis is similar in usage to other command line utility on modern machines.

qlever -gis -p 1234 where the get-data and index don't pay attention to the port flag since only --start need it.

in addition, qlever -gis is the same as qlever -sig, they are treated as a bunch of boolean flags that can be pattern matched against. It seems to me that that wouldn't be an issue since the order of operation is pretty initiative to the end-user (no one wants to index before getting the data).

Argument for the second approach:

let's take git add and git rebase as an example.

I believe the git (and docker) designed in this manner because each action contains ALOT of flags and they can easily conflict with each other and some of them share the same alias.

case in point: git add -i (git add --interactive) leads to completely different behavior than git rebase -i (git rebase --interactive).

doing that in python requires the definition of subparsers which is of course possible and even allows for custom help for each action: qlever get-data --help will display relevant flags for get-data only.

My 2 cents

providing a port number when indexing qlever --index --port 1234 is not a deal breaker, since it's the port can be simply ignored or handled accordingly during the structural pattern matching of the args namespace.

qlever-control has about around dozen flags. using the second approach for will require multiple --help to explore all the possible flags that qlever-control has to offer.

tldr;

• approach 1: easy to implement, abbreviation chaining, less than optimal auto-completion experience.
• approach 2: && chaining, pretty good auto-completion experience, separate --help for each action

[bradenmacdonald]

For what it's worth, I personally prefer the second approach as it's more consistent with other tools and doesn't require learning any new "chaining" syntax. Anyone can see qlever get-data && qlever index && qlever start and knows what it means.

Also, is it actually that useful to support arbitrary chaining? For example nobody is going to run qlever start index get-data in that order. So perhaps there is another approach which is to alias some common sequences together such that get-data, index, and start can be triggered by the shortcut qlever launch. Or you can make start specifically accept some additional arguments like qlever start --get-data-if-needed --rebuild-index-if-needed.

[hannahbast]

@bradenmacdonald Thanks + my thoughts have been going in the same direction. In our internal uses of the qlever script, we use chaining a lot, so it definitively is useful. And the number of useful combinations is not so small. But as you write, one could define shortcuts for certain chains or just write the slightly more verbose qlever ... && qlever ... && etc..

So I guess, we will go with that.