Discuss: CLI syntax sometimes requires subcommands to be named after project-specific predicates

[aaronsteers]

The general best practice for CLI subcommands is

cli-exec COMMAND SUBCOMMAND --option-a=val --flag-b

However, Meltano's CLI often requires the object of the command to be specified before the subcommand is called.

For instance, we have:

meltano config my-plugin set SETTING VALUE

Whereas a more traditional CLI invocation pattern would be:

meltano config set PLUGIN SETTING VALUE

Or:

meltano config set --plugin=PLUGIN SETTING VALUE

Or the fully explicit:

meltano config set --plugin=PLUGIN --setting=SETTING --value=VALUE

Question

Should we look at unwinding this convention, and move towards a more standard convention where the top-level command or command group is followed by the subcommands, rather than interspersing commands and subcommmands with what otherwise would be

Backwards compatibility

If we do this, we'd likely want to explore if these could still be synonyms for backwards compatibility reasons:

meltano config PLUGIN set SETTING VALUE                             # Current
meltano config set PLUGIN SETTING VALUE                             # New (concise)
meltano config set --plugin=PLUGIN SETTING VALUE                    # New (explicit)
meltano config set --plugin=PLUGIN --setting=SETTING --value=VALUE  # New (verbose)

Related

• bug: Unable to get --help for meltano config ... set without a project dir context #7136

[tayloramurphy]

@aaronsteers I'm in favor of this. It aligns with our contributor guide https://docs.meltano.com/contribute/cli and also follows the implementation we've had for many of our more recent commands:

meltano schedule set <schedule_name> --job <new-job>

meltano job set <job_name> --tasks

meltano environment list

meltano environment add <environment_name>