> On Mar 28, 2025, at 8:58 AM, cpu...@gmail.com <cpui...@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.and...@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/FB126426-D302-48E3-87FF-D2787EBAF894%40newclarity.net.
