Would it make sense to include structured input types similar to how zerolog works?

[sheldonhull]

One thing I really like about zerolog is using zl.Error().Err(err).Str(prop).Msg("Foo"). I know pterm is more visual oriented than structured logging oriented, but there could be some nice usage here starting with pterm.Error.Err(err).WithScopeAndLine() for example. If there is not a custom message needed then specifically printing the error with details without needing to do string formatting could be useful.

The other part about providing pterm.Debug.Interface("mystruct",struct).Println("Foo") might be useful to simplify providing formatted input name/value pairs for output/debugging.

[MarvinJWendt]

I like the idea, but I don't know all the "logging magic" and best practices. I would definitely need someone to help me with the planning of such a feature, as I don't use loggers often (I am more of a CLI tool person ^^).

However, currently you could do that by creating an own printer:

	printError := pterm.Error.WithShowLineNumber().WithScope(pterm.Scope{Text: "some-scope"}).Println

	err := errors.New("some error")
	printError(err)

[sheldonhull]

Revisited this issue after serving Charm release their new logging package. https://github.com/charmbracelet/log

Still using pterm for most projects but having an option to toggle structured logs out and provide name value pairs would be interesting. Might also pair well with the experiential slog proposal, ie needing compatible with this later on.

Pterm fits an interesting area as I use it for pretty output tooling but often it's primary usage crosses over into a leveled logger for me.

[MarvinJWendt]

I'll see what I can do 😄
I still like the idea of logging in PTerm, but I'll have to dig a bit into the performance aspect of it. Packages like zap, logrus, zerolog, etc. are very well tuned, so that the log printing doesn't decrease the overall performance. Since PTerm is (most likely) only used in CLIs, we didn't prioritize performance, as it doesn't matter if a CLI tool is 1ms faster or not. When PTerm introduces logging, this could lead to people throwing PTerm into high scalable services. Then the logging could become slow if it's called thousands of times per second.

If we implement logging, I think we'll most likely state that it's not for high performance applications.

[MarvinJWendt]

The proposal for structured logging in the standard library was just accepted: golang/go#56345

I will wait for it to be stable, and maybe we can integrate it into PTerm, so that our structured logging is compatible with the standard library. Will be interesting!

[MarvinJWendt]

The proposal was accepted and is now to be discussed in #470.
Thanks for the suggestion and the contribution! :)