We should prettify the output message cosmetics for the secrets-delete command.
(1) For example, when a user tries to delete secrets without specifying any argument, the client replies:
$ reana-client secrets-delete
==> SUCCESS: Secrets were successfully deleted.
The message is very misleading, because nothing was deleted. It would be better to print a message to that effect, so that users should specify the name of the secrets to be deleted.
(2) Another example: when we successfully delete some secrets, we print:
$ reana-client secrets-delete foo bar
==> SUCCESS: Secrets foo, bar were successfully deleted.
However, when we add some secrets, we print a list:
$ reana-client secrets-delete foo bar
==> ERROR: Secrets ['foo', 'bar'] do not exist. Nothing was deleted
We should use simple list in this output as before (and not Pythonic lists).
(3) Note the help messages e.g. secrets-add speaking about USER=reanauser and PASSWORD. This may be counterproductive, since it may lead people to think that this is for uploading REANA user name and passwords, as it were? It may be better to use another (and more realistic) example, such as RUCIO_USERNAME in place of USER, and VOMSPROXY_FILE instead of file. (Or else use CERN_USER and keytab, but remove USER and PASSWORD.)
P.S. Note that some of these are solved in reana-client-go, some of these would still apply.
We should prettify the output message cosmetics for the
secrets-deletecommand.(1) For example, when a user tries to delete secrets without specifying any argument, the client replies:
The message is very misleading, because nothing was deleted. It would be better to print a message to that effect, so that users should specify the name of the secrets to be deleted.
(2) Another example: when we successfully delete some secrets, we print:
However, when we add some secrets, we print a list:
We should use simple list in this output as before (and not Pythonic lists).
(3) Note the help messages e.g.
secrets-addspeaking about USER=reanauser and PASSWORD. This may be counterproductive, since it may lead people to think that this is for uploading REANA user name and passwords, as it were? It may be better to use another (and more realistic) example, such as RUCIO_USERNAME in place of USER, and VOMSPROXY_FILE instead of file. (Or else use CERN_USER and keytab, but remove USER and PASSWORD.)P.S. Note that some of these are solved in
reana-client-go, some of these would still apply.