-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Finalize and expose the new logger interface #1270
Comments
The interface was kept intentionally closed to make sure it's the best we can do. However, there is some work going on in the Go community to add a structured logger to the standard library. Let's see how that works out, before introducing a custom interface. |
Any updates on the customer interface? Or switching to stdlib slog entirely? |
Yes, the plan is to switch to slog. I'm working on a solution to make sure we can make the switch in a backward compatible manner. |
Preflight Checklist
Problem Description
A new Logger interface has been introduced to prepare dropping JWW as a dependency (at least from the code, it's still used as the default logger implementation for backward compatibility reasons).
As pointed out in #1268 though, there is no way to provide a custom implementation at the moment. While I don't necessarily see that as a critical problem (JWW works and it's a dependency anyway), we definitely want to drop JWW, so allowing users to customize the logger is inevitable.
Proposed Solution
Expose a
WithLogger
option for Viper to allow customizing the logger implementation.Alternatives Considered
No response
Additional Information
Before exposing the interface, we need to finalize it (ie. agree that the current contract is suitable for Viper in the long-term). The current interface is modeled directly after the JWW usage.
Logger abstractions out there:
The contract should be defined by Viper as the consumer of the interface.
The text was updated successfully, but these errors were encountered: