> Can you link that discussion, please, for those of us who may have not seen the discussion nor be able to find the specific discussion via search?
https://github.com/golang/go/issues/56345 (super-thread) https://github.com/golang/go/issues/58243 (what to do about context) There's more scattered in other closed issues. I remain totally impressed by Jonathan Amsterdam's willingness to have kept up with things ... particularly with contexts the API evolved a bit in ways that were difficult to work out before lots of public commentary. > it still does not solve the inconsistency problem across 3rd party packages used by a Go app FWIW I think pkg.go.dev "Imported by" numbers show adoption of slog has been pretty good - I am going by memory but slog is up to 40k importers, and I'm fairly certain that logrus, zap, and zerolog have grown by maybe a few thousand since slog was included in the standard library. In theory custom wrapping of slog Handlers is flexible enough to integrate diverging opinions between dependencies of a project. I don't know how frequently that is leveraged in solutions. On Saturday, March 29, 2025 at 9:36:00 PM UTC-7 Mike Schinkel wrote: > > On Mar 28, 2025, at 8:58 AM, cpu...@gmail.com <cpu...@gmail.com> wrote: > > > > I'm in the process of converting our application (evcc.io) from using > spf13/jwalterweatherman for logging to log/slog. > > This is a very serendipitously timed discussion (for me) since yesterday > and today I have been working on how to configure logging for a new project > I am working on. > > The solution I have is built on top of slog and leverages slog.Default() > and then uses a package variable `logger` defined in every package I write. > I add a `logger.go` file to every one of my packages and then add this line > of code which uses a small package I write with a `Logger` type simply to > embed slog.Log so I could add my own methods and to preprocess calls to > *slog.Logger if I find that to be needed down the road. > > var logger = logging.NewPackageLogger("<package_name>") // UPDATE this > with your package name > > I don't love this approach because it requires adding an updated version > of this file to every package I write but it feels the most workable > solution I have tried to date, and this is about my 5th iteration of trying > to find a workable solution for logging. (BTW, sure would be nice if Go had > a way to capture the name of the current package using a well-known > constant like PACKAGE_NAME, but I digress.) > > Here is the current state of my logging package along with a few examples > of using it: > > https://gist.github.com/mikeschinkel/3b1fb9ac4bbc200c95d0fc31692959ce > > I have not yet run this approach in production so I do not know if I will > discover it to be unworkable. I decided to mention it here to solicit input > from anyone who might be able to find a reason this approach might not be > workable. > > > On Mar 29, 2025, at 5:44 PM, Andrew Harris <harris...@gmail.com> wrote: > > > > The question of how to pass loggers around was discussed at significant > length in GitHub, and drew a lot of strong opinions. > > Can you link that discussion, please, for those of us who may have not > seen the discussion nor be able to find the specific discussion via search? > > > 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. > > Yes. > > While I do appreciate slog for being a big improvement over log, it still > does not solve the inconsistency problem across 3rd party packages used by > a Go app. And the fact there are a lot of strong conflicting opinions > ensures we won't see a convergence to a defacto-standard approach to > logging unless and until there emerges some new innovation for logging from > the Go team. > > -Mike > > P.S. Maybe Go could add a way for a package to register some sort of > middleware hook so that a developer wanting to orchestrate the use of > logging across all packages use could do so like we can currently handle > HTTP requests and responses? OTOH, I almost feel like logging needs special > handling by the compiler given how opinions regarding best practices > diverge to such an extent... 🤔 > > > -- 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/d85ef0d4-046a-4af0-975c-4245241cafe4n%40googlegroups.com.
