Closed yaziine closed 6 years ago
I'm not sure we should go as far as abstracting logging: This is an opinionated library and IMO this kind of library can choose how it logs (whether by using the std logger or a third party library) and simply allow the user choose the output and the level if any; Sarama and a lot of other libraries already do that. Logging the right information at the right place is a feature provided by the library and not having to abstract that would allow us to be more flexible.
Maybe we can do as Sarama does. By default, it logs to ioutil.Discard but if the user wants to retrieve the logs, he has to set the Logger
variable to redirect the output where he wants. WDYT guys?
Something like that would be cool yeah, a library shouldn't print anything by default.
a library shouldn't print anything by default
It's for why I want to remove the loggers because it's not common (based on my experience) to have library logs as a project will do (think of regula for example). But the way of Sarama is good I think. Let's wait for @tealeg input.
It's for why I want to remove the loggers because it's not common (based on my experience) to have library logs as a project will do (think of regula for example).
Not printing by default and not providing logs are two different things. It's important for a library to log when it's doing internal complex stuff, regardless of the output, and it is the user's choice to display these logs or not.
For me (until these days) a library didn't have to log. If something goes wrong, it just returns errors and the users will manage that with logs and so on. But now it's more clear for me.
I like the ioutil.Discard
approach - let's do that.
Fix #10.
Notes: