If your modules are mostly structs with lifecycle methods, do it like http.Server where the logger is a field (or option passed into the constructor).
Else if your modules take contexts, you could consider having your own WithLogger / FromContext funcs to pass a logger in a context. An advantage of this over a (declined in slog) global context key is that this allows your consumers to target your module with a specific logger. Finally, you can do the same as log / slog are doing with Default() SetDefault() possibly guarded with an RWMutex, or just document that it's unsafe to change after start. Personal preference is for 1, and whether you take a Logger vs Handler would just be if you have a preference for a different frontend. - sean On Wed, Aug 23, 2023 at 7:09 PM TheDiveO <harald.albre...@gmx.net> wrote: > Up front, I admit my sin of arrogance in giving structured logging the > slip these past years and misusing logrus just as a text logger with > multiple log levels. This question is kind of my atoning... > > For preparation, I've read through (today's?) Go slog blog post, as well > as some comparably recent 3rd party blog posts about Golangs new slog. > > What I haven't found (or maybe stubbornly refused to see) is: as I want to > convert my existing consumable modules to slog, how am I going to be a good > citizen, so other modules can easily consume my modules with proper control > over logging? How am I giving my module "customers" control over per-module > (but not necessarily per-package) logging? Are there already best practises > and what are they? > > While ponding these questions, I would suspect, that creating a per-module > default "slogger" when none has been set in a module's init() would be a > bad idea: due to the order of module initialization, all my module > customers/consumers would end up with the default slogger that mostly would > not fit their needs. > > Simply exposing a public variable would be either suffering the init > problem, or alternatively, I would create default sloggers that then have > to be garbage collected anyway. > > And now, Ladies and Gentlemens, show me your consumable slogging please! I > want to learn! > > -- > 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 on the web visit > https://groups.google.com/d/msgid/golang-nuts/cc4f2bcb-4972-4966-b2ff-341f29339d67n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/cc4f2bcb-4972-4966-b2ff-341f29339d67n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGabyPp%3DFh5ff7bf0VWr-KttLxreMHEU_0-yqdVjCJKB8UjTwQ%40mail.gmail.com.
