How do we want the CLI UX to be for acting on "all" the things

[tayloramurphy]

From #5961 (comment) I went through the CLI and found all of the instances where we're doing an action that includes all of something.

• meltano config <plugin> list # lists all settings for a given plugin
• meltano discover all # discover all plugins
• meltano install # installs all plugins
• meltano job list # list all jobs
• meltano schedule list # list all schedules
• meltano select <plugin> --list --all # list all available entities and attributes
• meltano test --all # run all tests for all plugins
• meltano test <plugin> # run all tests for one plugin
• meltano lock --all #proposed - TBD

this is fairly inconsistent behavior across the entire command line.

My initial vote would be to have --all be the flag and the recommended way to do things, but then be backwards compatible with the current behavior for some commands:

• meltano config <plugin> list - keep same
• meltano discover all --> meltano discover --all - perhaps meltano discover could work as well
• meltano install --> meltano install --all keep current behavior still
• meltano job list --> meltano job list --all keep current behavior still
• meltano schedule list --> meltano schedule list --all keep current behavior still
• meltano select <plugin> --list --all - I think keep the same?
• meltano test --all --> add meltano test as a less preferred option
• meltano test <plugin> --> meltano test <plugin> --all keep current behavior still
• meltano lock --all #proposed - perhaps still allow meltano lock

@meltano/engineering @DouweM @pnadolny13 thoughts?

[pandemicsyn]

Personally, if we expect folks to want --all most of the time when doing X, then I think that should be the default action. So I'm a big fan of having something like:

meltano job list where meltano job list --all is implied.

Especially where there's no alternative to --all. We don't currently support meltano job list --etl-only so why make me type --all all the time?

[tayloramurphy]

@pandemicsyn I agree! I meant to imply that with my proposal - how can I format that to make it clearer?

Basically I want meltano job list to be meltano job list --all and vice versa.

[pandemicsyn]

Ah gotcha, maybe tables to the rescue ?

Command	Default/implied behavior
meltano install	meltano install --all
meltano job list	meltano job list --all
meltano test	meltano test --all

or

Command	Default flags
meltano install	--all
meltano job list	--all , --format="text"
meltano schedule list	--all , --format="text"
meltano test	--all

[aaronsteers]

Adding my comments from our related discussion on the #6114 PR:

I think there are two categories of commands:

1. Those that should default to noop (actually exit code 1) if no direct targets are passed. (e.g. meltano run as a silly example, but meltano config set as a more realistic one).
2. Those that should default to '--all' if no direct targets are passed.

What we think the reasonable default is of the above, may not be obvious to the user, and it could also change over time. For instance, we don't have meltano config get --all but in future, we could! To avoid writing a convention that changes or breaks according to whether --all is viable in the context, we were biasing towards accepting --all as an explicit way to say "yes, I really mean everything".

With the above context and framing, meltano lock could fail on it's own or succeed according to the decisions we make here in this PR, but meltano lock --all would be an intuitive way to run everything without having to remember the outcome of our decision on this point 😄 .

So, I'm actually fine with either of these behaviors:

• meltano lock is a noop with exit code 1
• meltano lock is a synonym for meltano lock --all

But meltano lock my-plugin definitely does not do the "--all" behavior, and meltano lock --all my-plugin is an illegal operation because --all and the named plugin are mutually exclusive.