Add `--interactive --all` CLI flags in `meltano config set`
Based on recent discussions around the difficulties in knowing which settings to configure when adding a new plugin, we should add an interactive mode for setting all setting for a plugin, or any specific settings value.
Something like...
> meltano config dbt-snowflake set --interactive --all
You are now configuring the "dbt-snowflake" transformer plugin.
For help, please refer to plugin documentation: https://...
We will now step through each setting. Leave any entry blank to skip,
or enter a new value. Password values will automatically be hidden
from display for any settings of type 'password'.
Press Ctrl+C to cancel at any time.
Setting #1: project_dir
Description: The root dbt path.
Type: string
Default value: $MELTANO_PROJECT_ROOT/transform
Current value: (none)
New Value: _
(skipped)
....
Setting #7: snowflake_user
Description: The username to use in Snowflake authentication.
Type: string
Default value: (none)
Current value: (none)
New Value: snowflake_prod_user
Value saved successfully to meltano.yml!
Setting #8: snowflake_password
Description: The password to use in Snowflake authentication.
Type: password
Default value: $MELTANO_PROJECT_ROOT/transform
Current value: (none)
New Value: **********
Value saved successfully to Meltano System DB!
Spec Details
- Interactive behavior is triggered bia the
--interactive
flag inmeltano config ... set
. - Interactive behavior can be triggered for a single setting or with
--all
to set all settings associated with the given plugin. - The
--all
option requires the--interactive
flag. If--all
is specified without--interactive
, Meltano should fail. - After each setting is set, Meltano should respond with
Value saved successfully to _<store>_!
- The store could be
.env
, the SystemDB, or to Meltano.yml. - Confirming and saving after each setting is set gives real-time feedback to the user about changes they have applied, and allows the remaining operation to be canceled without loss of any setting values already saved.
- The store could be
- Individual settings should be skippable.
- Password fields should either print asterisks or simply not echo anything while users are typing.
- The new setting value should not be provided inline at the command line if
--interactive
is set. So, passing the setting value and also passing--interactive
should cause Meltano to fail.
Ability to "skip" settings
Skipping a setting may not be intuitive if done inline with the setting value input.
Setting #1: project_dir
Description: The root dbt path.
Type: string
Default value: $MELTANO_PROJECT_ROOT/transform
Current value: (none)
Would you like to set a new value? [Y/n]: n
Skipped.
Setting #2: snowflake_user
Description: The username to use in Snowflake authentication.
Type: string
Default value: (none)
Current value: (none)
Would you like to set a new value? [Y/n]: Y
New Value? []: snowflake_prod_user
Value saved successfully to meltano.yml!
...
Without a separate prompt to skip or set the value, the user would generally have to type something like an empty string or s
for skip, or similar. However, those are potentially valid answers to the new value prompt.
Phases
- The initial merge should at minimum provide
--all --interactive
support. - Optionally, setting only one value (
--interactive
without--all
) can be included in initial scope or added in a subsequent iteration.- When setting only a single value, presumably we do not need to allow the "skip" option described above, since the user can simply abort (
ctrl+c
) to cancel if they do not want the value set.
- When setting only a single value, presumably we do not need to allow the "skip" option described above, since the user can simply abort (
- Not required in this first iteration, but a future iteration should require users to first define a setting's type if the type is not yet set. Would be a path for resolving Change default behavior in `meltano config ... ... (#2768 - closed). For example, if the user runs
meltano config tap-snowflake set --interactive snowflake_password
, that should require the user to first define the settingkind
(kind ispassword
in this case), which then drives correct parsing and storage of the provided value.
Edited by AJ Steers