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.
