Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: pass logger into repo and client #385

Merged
merged 5 commits into from
Sep 20, 2022

Conversation

asraa
Copy link
Contributor

@asraa asraa commented Sep 16, 2022

Signed-off-by: Asra Ali [email protected]

Fixes #376

Please fill in the fields below to submit a pull request. The more information that is provided, the better.

Release Notes:

* feat: Allows passing an optional logger into `repo`. Default uses `io.Discard` to swallow logs.
* feat: Exposes a `repo.NewRepoWithOpts` that can be used to instantiate a repo with repo options like prefix, indent, hash algorithms, and logger.

Types of changes:

  • Bug fix (non-breaking change which fixes an issue)
  • [ x ] New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Description of the changes being introduced by the pull request:
Client and Repo can now pass in an optional logger. This will not break any existing clients, the argument is optional.

Please verify and check that the pull request fulfills the following requirements:

  • [ x ] Tests have been added for the bug fix or new feature
  • Docs have been added for the bug fix or new feature

**This is pretty preliminary, please let me know if you agree/disagree with my approach.

I would still need to fix the CLI as a follow-up, this PR as it stands totally removes logging since none is explicitly passed.
**

Sorry, something went wrong.

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[email protected]>
@asraa asraa requested a review from joshuagl September 16, 2022 16:12
znewman01
znewman01 previously approved these changes Sep 16, 2022
Copy link
Contributor

@znewman01 znewman01 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW nice refactor with the "Opts" pattern 👍

pkg/keys/deprecated_ecdsa.go Outdated Show resolved Hide resolved
znewman01
znewman01 previously approved these changes Sep 19, 2022
Copy link
Contributor

@znewman01 znewman01 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Linter is a nice touch

@asraa asraa merged commit f237d7c into theupdateframework:master Sep 20, 2022
@@ -32,7 +33,7 @@ See "tuf-client help <command>" for more information on a specific command.

if cmd == "help" {
if len(cmdArgs) == 0 { // `tuf-client help`
fmt.Println(usage)
fmt.Fprint(os.Stderr, usage)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is usage going to stderr?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤷 I've seen it both ways. There are some tools that define an explicit, strict "everything that gets logged to stdout must be computer-readable" philosophy and apply that to help text too. Many tools do, of course, print usage on STDOUT.

See for instance this request for usage on STDERR. I particularly like the recommendation to follow picocli (just one example):

when the user specified invalid input, the error message and usage help should be printed to stderr, but when the user requests help with --help, the usage help should be printed to stdout so users can pipe the output to tools like grep and less.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, thank you for the comment: Yeah, I think I originally assumed that help should be part of STDERR, but here, since the user explicitly requested for help, I think I concur, it should be STDOUT. I'll put out a fix PR.

@@ -58,7 +58,7 @@ See "tuf help <command>" for more information on a specific command

if cmd == "help" {
if len(cmdArgs) == 0 { // `tuf help`
fmt.Println(usage)
fmt.Fprint(os.Stderr, usage)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

go-tuf logs to stdout/stderr when used as a library
4 participants