I've found implementing LogValuer can be a useful approach as well. Depending on the package, it can be enough to suggest a package doesn't need to be doing any logging, and if refactoring code from unstructured to structured logging it's useful in any case. On Wednesday, August 23, 2023 at 12:29:31 PM UTC-7 Sean Liao wrote:
> 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....@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...@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/370fc8ef-f30b-4570-85d3-8f7eec7457f7n%40googlegroups.com.
