Feature/258 implemented initial cli UI

[ckunki]

Closes #258

[tkilias]

how do you plan to use this? inside the function call, you only get the value of argument or option, but not this scs_key

[ckunki]

inside the function call

If you mean the click command, e.g. save() then I agree, correct, arg scs_key is not available there.

I planned for the following strategy:

• In the click commands only evaluate the value passed for each option
• pass the values as kwargs to the processing

The processing then maps the values (kwargs) to the initial option declarations for finding the scs_key related to each value.

[ahsimb]

I am probably not up to speed yet, coming back from holiday. Why do we need to re-implement the CLI, that has been previously done in PEC?

[tkilias]

I am probably not up to speed yet, coming back from holiday. Why do we need to re-implement the CLI, that has been previously done in PEC?

We discussed this and actually thought about using PEC. However, with PEC you get the SLC Tool and all its dependencies into the mix. Furthermore, we need some more information for SCS, so we decided to define it independently.

[ahsimb]

I find the name of the file a bit confusing. Would "common.py" be a better name?

[ckunki]

Yes, definitely.
I will rename the file.

[ahsimb]

Why do you need to make a copy of kwargs?

[ckunki]

This seems to have been a remainder of initial experiments, which now is obsolete.
Thanks!
See next push removing the copy.

[ahsimb]

You may need to add the parameter hide_input = True

[ahsimb]

Also, why don't we have kwargs in the ScsSecretOption. while we do have them in the base class?

[ckunki]

The user should be able to type passwords interactively or provide them by related environment variables.

Passing passwords directly as explicit values of the related CLI options is discouraged, as the value will be copied to the shell history and hence is a security risk.

Click offers many features for password-related CLI options. However, I didn't find a way to prevent the user from passing the password directly as the value of the related CLI option.

If we want to allow passwords to be specified only via env or interactive input, then we need a custom solution.

The constructor of class ScsSecretOption therefore adds is_flag=True:

super().__init__(
    name,
    metavar=metavar,
    type=bool,
    is_flag=True,
    help=f"{prompt}  [env var: {envvar}]",
    scs_key=scs_key,
)

That makes these options flags without values, hence the user cannot specify a value directly on the CLI, but only has the options to either set the related environment variable or type the secret interactively.

[ckunki]

In order to specify a password, the user can call

scs configure onprem --db-password 

Then the application is planned to inspect the related environment variable SCS_EXASOL_DB_PASSWORD.

If the SCS_EXASOL_DB_PASSWORD is unset, then the application is planned to ask the user to type the password interactively, hiding the typed characters by getpass.getpass().

However, following this implementation strategy, the user cannot use

scs configure onprem --db-password "some password"

The user can also omit the option, configure some other values, and add the password later on

scs configure onprem --db-host

We also plan to have additional commands check and show for checking the current SCS content to be sufficiently complete and for showing the stored configuration (hiding the passwords), see ticket #257 for more details.

[ckunki]

Many thanks to @ahsimb for clarifying and constructive discussion.
I think we are now on the same page.

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud