zap for example provides both: RedirectStdLog to capture all output and NewStdLog to produce a preconfigured std log.Logger
On Sunday, August 29, 2021 at 8:10:54 AM UTC+2 Amnon wrote: > Yes, this is a massive pain. > > The standard library's log.Logger is not an interface, despite ending in > er. > > If it was an interface, it would be easy for third party packages to > implement it, and then it would > be a lowest common denominator for any package where doing some logging > could be useful. > > Unfortunately it is too late to change this. > > On Sunday, 29 August 2021 at 00:38:50 UTC+1 amits...@gmail.com wrote: > >> Hi all, a huge disclaimer - I am not familiar with the design >> decisions and internal details of anything that follows. They are >> coming from the point of view of a consumer of the language and the >> ecosystem and also someone trying to write about these things for an >> audience. >> >> Say I have an application - a HTTP server, where I initialize a >> log.Logger as implemented by the standard library and then I inject >> that into the handler functions where they call the Printf() or the >> other methods to log stuff. Say I have also configured a middleware to >> log data for every request, once again using the Printf() and family >> functions. >> >> Now, I want to implement some levelled and/or structured logging. So, >> here's my expectation - I should just be able to update the initial >> code and everything else should not be changed. Of course, in due >> course of time, I will update those to take advantage of the actual >> functionality offered by those libraries - levelled logging, >> structured logging. But, initially, my code should just build and >> work. Many years back, that's how I really found >> https://github.com/sirupsen/logrus useful and exciting. However, some >> more performant and recent packages don't seem to have that >> compatibility as a goal. For example, https://github.com/uber-go/zap >> doesn't AFAICT implement the Printf() or other functions. However, >> https://github.com/rs/zerolog does, which is great. >> >> I imagine this possibly is due to the standard library not exporting >> publicly available types for - logging handlers, formatters (encoders) >> and such that third party packages have difficulty implementing these >> in standard library compatible way? >> >> To summarize, I would have really wanted a way to avoid my code >> becoming tightly coupled with the logging library I am using but that >> seems to be hard at this stage. >> >> What does the community think? >> > -- 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/25e2dbfb-7319-4d13-a5f5-d93003f315ddn%40googlegroups.com.
