Create slogr implementation for slog package

[Dentrax]

slog is a new standard library package which could provide structured logging with levels. ¹

I'd be great to create a new separate repo called slogr for slog logger. Any thoughts on this?

Footnotes

1. https://www.youtube.com/watch?v=gd_Vyb5vEw0 ↩

[pohly]

Do we need a separate repo for it?

Pro: versioning separately from go-logr/logr
Con: one more repo to maintain, like funcr it won't add dependencies

I think the versioning aspect is significant enough that it should be a separate repo.

@Dentrax: do you want to work on such a slogr LogSink?

[Dentrax]

Do we need a separate repo for it?

I'm not so sure, just noticed there are a bunch of logger implementations separated along different repos: https://github.com/go-logr/logr#implementations-non-exhaustive

do you want to work on such a slogr LogSink?

Not making promises, but maybe I can work on this. But don't know where to start. Is there any documentation for this?

[pohly]

So this is basically a feature request to create an slogr. That's fine and definitely something that someone should do, but let's wait with creating the repo until there is something that we can put there.

The other loggers could serve as example. There's no dedicated documentation for "how to write a LogSink".

[pohly]

Such an slogr implementation is probably going to be more complicated. We also need to consider how libraries using logr will interact with binaries using slog. For example, consider an binary which creates a slog logger using some kind of implementation, then installs it as global slog logger and/or adds it to a context.

Now a library calls klog.FromContext. It would be neat if that call then returned an slogr bridge for whatever slog would be using.

Likewise with klog.NewContext: if a binary calls that and then some library uses slog, it would be good if that library would log through the Logger.

This implies that slogr has to be clue code in go-logr, and that go-logr itself needs to be built differently depending on the Go version, once slog becomes part of some release.

[pohly]

https://github.com/pohly/zapr/tree/slog has some preliminary slogr implementation.

I think the code should be in logr because then logr.SlogFromContext and logr.NewContextWithSlog become possible such that a logger set with logr.NewContextWithSlog can be retrieved with logr.FromContext and vice versa.

[thockin]

We now have slog support (unreleased, but should be in next tag). We'll evolve it more but I will close this issue now.