Improve the CLI experience

[rdimitrov]

The following PR adds informative messages about each CLI command upon successful completion. Closes #11

One thing I'd like to note is the output for tuf root-keys previously consisted only of the JSON encoded root keys and now there's a helpful message before that. This might break stuff in case there's some automation built around it, so let me know if it might make sense to revert that change specifically.

Examples of the resulting output:

./tuf init
Repository initialized
------------
# Same for root, targets, snapshot and timestamp
./tuf gen-key root
Enter root keys passphrase: 
Repeat root keys passphrase: 
Generated root key with ID 157a50daaa57d68518ea1a47190e9ffd4be1985647f320409fa28d8c07b1ab6a
------------
./tuf revoke-key root a94ce6fd989d04d5d86202a80b320b3ab1ae60d44c693aad41be76ab5e6f568c
Revoked root key with ID a94ce6fd989d04d5d86202a80b320b3ab1ae60d44c693aad41be76ab5e6f568c
------------
./tuf sign root.json
Signed root.json with 1 key(s)
------------
./tuf add bb/cc/aa
Added/staged targets:
* bb/cc/aa
------------
./tuf add
Added/staged targets:
* bb/vv
* bbbb
* bb/cc/aa
* aaaa
------------
./tuf remove bb/vv
Removed targets:
* bb/vv
Added/staged targets:
* aaaa
* bb/cc/aa
* bbbb
------------
./tuf remove --all
Removed targets:
* aaaa
* bb/cc/aa
* bbbb
There are no added/staged targets
------------
./tuf snapshot
Staged snapshot.json metadata with expiration date: 2021-10-06 10:56:49 +0000 UTC
------------
./tuf timestamp
Staged timestamp.json metadata with expiration date: 2021-09-30 10:57:27 +0000 UTC
------------
./tuf set-threshold root 2
The threshold for root role is 2
------------
./tuf get-threshold targets
The threshold for targets role is 1
------------
./tuf commit
Committed successfully
------------
./tuf root-keys
The resulting JSON should be distributed to clients for performing initial updates:

[{"keytype":"ed25519","scheme":"ed25519","keyid_hash_algorithms":["sha256","sha512"],"keyval":{"public":"3e15b2f364cd35f2a2ee3019089e9dace8fa6daaaa2a895ff0ad13f6d365d9b2"}}]
------------
./tuf clean
Removed all staged metadata and target files

[joshuagl]

Nice the CLI output you've shown here certainly looks more helpful for folks running the tools interactively.

One thing I'd like to note is the output for tuf root-keys previously consisted only of the JSON encoded root keys and now there's a helpful message before that. This might break stuff in case there's some automation built around it, so let me know if it might make sense to revert that change specifically.

As you've identified, this feels like it could break workflows. If someone is piping the output of the tool into a file, that file won't be parseable as JSON after this change.

I wonder whether we add a --verbose/-v option to enable the richer output you've implemented here? Or, maybe default to this new (breaking) behaviour and instead add a --silent/-s option to disable the detailed output?

What do you think @asraa @hosseinsia @mnm678 @trishankatdatadog ?

[mnm678]

I wonder whether we add a --verbose/-v option to enable the richer output you've implemented here? Or, maybe default to this new (breaking) behaviour and instead add a --silent/-s option to disable the detailed output?

My vote would be for the -v, especially for the tuf root-keys command, as it's designed to output json that can be used directly by tuf-client init.

[mnm678]

I left a few nits, but mostly this looks good. My only concern relates to my comment above about root-keys.

[rdimitrov]

I wonder whether we add a --verbose/-v option to enable the richer output you've implemented here? Or, maybe default to this new (breaking) behaviour and instead add a --silent/-s option to disable the detailed output?

My vote would be for the -v, especially for the tuf root-keys command, as it's designed to output json that can be used directly by tuf-client init.

Thanks for your feedback, @mnm678 👍

I'm leaning towards being verbose by default as it's more common for new users to use it interactively in the beginning (making it more user-friendly but also have the -s flag if one wants to automate/pipe the output). Nevertheless, I agree that this could be a breaking change for some, so I don't mind keeping tuf root-keys silent by default 👍

As for the other commands, I don't think they can break something, so I guess we can keep their messages verbose by default, right?

[coveralls]

Pull Request Test Coverage Report for Build 1319883009

• 57 of 63 (90.48%) changed or added relevant lines in 1 file are covered.
• 239 unchanged lines in 4 files lost coverage.
• Overall coverage increased (+0.1%) to 68.133%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
repo.go	57	63	90.48%

Files with Coverage Reduction	New Missed Lines	%
verify/db.go	11	85.71%
data/types.go	45	59.02%
local_store.go	73	75.93%
repo.go	110	73.92%

Totals
Change from base Build 1309536767:	0.1%
Covered Lines:	1982
Relevant Lines:	2909

---

💛 - Coveralls

[trishankatdatadog]

I'm leaning towards being verbose by default as it's more common for new users to use it interactively in the beginning (making it more user-friendly but also have the -s flag if one wants to automate/pipe the output). Nevertheless, I agree that this could be a breaking change for some, so I don't mind keeping tuf root-keys silent by default 👍

I don't think it's such a breaking change. We have done #143 which was definitely breaking, and we haven't seen complaints yet. But anyone who depends on this definitely should speak up. I'm in favour of more, not less, explicit error messages by default. New users should not just see something like tuf: signature verification failed.

[rdimitrov]

I'm leaning towards being verbose by default as it's more common for new users to use it interactively in the beginning (making it more user-friendly but also have the -s flag if one wants to automate/pipe the output). Nevertheless, I agree that this could be a breaking change for some, so I don't mind keeping tuf root-keys silent by default 👍

I don't think it's such a breaking change. We have done #143 which was definitely breaking, and we haven't seen complaints yet. But anyone who depends on this definitely should speak up. I'm in favour of more, not less, explicit error messages by default. New users should not just see something like tuf: signature verification failed.

I think so too 👍 In that sense, can we agree on leaving the more verbose output enabled by default and adding a -s/--silent option for commands such as tuf root-keys?

[joshuagl]

Can we call it -q/--quiet, that appears to be a more common in UNIX commands.

To address the concern about command output going directly into another command, we should put informative/diagnostic output on stderr and conventional output (JSON for other commands) on stdout. See https://pubs.opengroup.org/onlinepubs/9699919799/functions/stderr.html

[rdimitrov]

Can we call it -q/--quiet, that appears to be a more common in UNIX commands.

To address the concern about command output going directly into another command, we should put informative/diagnostic output on stderr and conventional output (JSON for other commands) on stdout. See https://pubs.opengroup.org/onlinepubs/9699919799/functions/stderr.html

Neat 👍 Will do that.

[rdimitrov]

I've applied the suggestions and added -q|--quiet mode for root-keys.

Although now that I'm thinking having both quiet mode and stream redirect might be unnecessary. Having the latter makes the quiet option obsolete I guess.

[joshuagl]

Yes, sorry I was unclear in my original response. You are correct. We should not need quiet mode because if diagnostics go to stderr and conventional output goes to stdout then tuf root-keys > foo.json would give you informative messages on the CLI and the JSON in foo.json.

[rdimitrov]

Yes, sorry I was unclear in my original response. You are correct. We should not need quiet mode because if diagnostics go to stderr and conventional output goes to stdout then tuf root-keys > foo.json would give you informative messages on the CLI and the JSON in foo.json.

Exactly 👍 I'll revert the quiet mode then

[joshuagl]

LGTM thanks Radoslav! Could we get some review from others, especially our more Go savvy maintainers?

cc @hosseinsia @trishankatdatadog @asraa @mnm678

[tamird]

This PR and various subsequent changes have made it considerably more noisy to use go-tuf as a library. Would it be possible to thread an io.Writer through rather than calling fmt.Print{f,ln} directly?