The question of how to pass loggers around was discussed at significant length in GitHub, and drew a lot of strong opinions. More so than other standard library stuff, any particular piece of the slog API is maybe less an eager endorsement of best practices, but more about matching what exists in other popular logging packages. Particularly context/logger usage was sort of a bright line division, I think a fair summary is that it's not an option for some developers, and for others it's admittedly a trade-off that makes sense because contexts are already plumbed through everything.
The jww package begins to address the question by using a configurable global logger, like slog.Default. Before moving away from that - and it might be enough, really, it's greatly simplifying - I think it might be worth working out what kinds of structure is already latent in the application. Personally I've come to prefer implementing the LogValuer interface and global loggers, except when there are really easy/obvious places to use child loggers. But, there are lots of opinions and lots of real-world examples of different approaches working out as well. On Friday, March 28, 2025 at 5:58:51 AM UTC-7 cpu...@gmail.com wrote: > I'm in the process of converting our application (evcc.io) from using > spf13/jwalterweatherman for logging to log/slog. One current pain point is > passing loggers around the application and deriving child loggers. With > using slog there are various options for doing that: > > Passing loggers: > > - pass parent logger as parameter > - pass a context and retrieve the parent logger from context value > > > Passing log attributes/groups to child loggers: > > - assign them to loggers and pass them via the logger (see before- > either as parameter or context value) > - assign them to context and retrieve them from context value for > assigning to the child logger > > Not sure those questions are clear enough, but let's try: are there > experiences what works "best" in larger applications? > > Cheers, > Andi > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/fea26fa0-e865-4f86-9989-47094eb365c2n%40googlegroups.com.