Use log/slog instead of log
#4635
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
|
Happy to break this up into chunks (maybe across package boundaries) if that's helpful. In general the two logging packages can coexist. |
weikanglim
reviewed
Jan 6, 2025
| @@ -213,7 +212,7 @@ func (cb *CobraBuilder) bindCommand(cmd *cobra.Command, descriptor *actions.Acti | |||
| consoleFn: func() input.Console { | |||
| var console input.Console | |||
| if err := cb.container.Resolve(&console); err != nil { | |||
| log.Panic("creating docs flag: %w", err) | |||
| panic(fmt.Sprintf("creating docs flag: %v", err)) | |||
There was a problem hiding this comment.
@vhvb1989 had mentioned something about log.Panic being preferable before, so curious what he thinks here.
weikanglim
reviewed
Jan 6, 2025
There was a problem hiding this comment.
Overall, I really like that slog exists and could really see its usefulness if we were to take advantage of the structured metadata. Currently, I'm undecided if I like slog better, as I still prefer simplicity of log and the only included --debug level. If we were to have plans to take full advantage of this, I could be convinced otherwise.
One thing that comes to mind is that our debug logs are intended to be a "somewhat dev-friendly message for debugging purposes" and it feels that the current handwritten Printf format strings do a slightly better job at that. With the structured formatting, the messages look "semi-structured" which right now doesn't look that great for me personally. Perhaps it's something for me personally to get adjusted with more time spent in these logs over time.
It also feels that slog.InfoContext and the likes are very specific to scenarios where ctx matters; and yet the codebase serves a simple CLI that is unlikely? to matter.
Just curious about your overall thoughts on this @ellismg. The simpler logging code of today is still pushing me towards keeping the simple Printf, but I wonder if you have some future ideas.
It's a reasonable point - There are a few things that motivated me to do this pass:
And, to be honest, things were quiet over the holidays and so it felt like if we wanted to make a run at adopting |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Go added
log/slogto the standard library in Go 1.21. It provides a leveled logging API that allows for structured logging. If this package had existed in the standard library when we startedazd, we would have used it overlog.This change moves us from
logtolog/slog.To do so, I've replaced all the calls to
log.Print,log.Printfandlog.Printlnwith calls toslog.InfoContext. If acontext.Contextobject was available in the method, I used it, otherwise I usedcontext.TODO()so we can go back and thread the context parameter. Passing the context object like this should allow us to tie these log messages to tracing spans at some point. In practice,slog.InfoContext(context.TODO, ....)behavesslog.Info(...)(sincecontext.TODO()is likecontext.Background()andslog.Infocallsslog.InfoContextwithcontext.Background().While
slogdoes have levels, for the first pass, I chose to always useslog.InfoContexteven ifslog.ErrorContextorslog.WarningContextmay have made more sense based on the log message. We can evolve this over time.Since
slogdoes structured logging, it is expected that insead of intermixing the logging message with the data to be logged, that you pass these as separate values, I did light editing of the logging messages when it made sense.Calls to
log.Panicandlog.Panicfwere replaced with direct calls topanic(perhaps with a call tofmt.Sprintfto produce the message to pass to panic) sinceslogdoesn't have helpers likePanicorFatal. This does mean we no longer log a message in these cases, but from inspection it felt like this would be OK.The
--debugoutput ofazdis slightly different after this change, since we now have a level printed for the log message and the data is printed after the message:Before:
After: