WIP: slog support #196

pohly · 2023-08-03T11:52:17Z

This adds APIs for converting between a logr.Logger and a slog.Logger. Glue code is needed in some cases.

The reasons for doing this in logr itself are a) easy access to the new API calls and b) it enables a future logr extension where logr itself manages a global default logger which can be provided by either a slog.Handler or a logr.LogSink, with conversion as needed by a client.

Since it was created, this PR was split into smaller PRs and will not get merged itself. I'm keeping it around as reference until everything is merged:

glue code: slogr: add glue code for logging to slog.Handler and with slog.Logger #205
conversion: slogr: restore original backend when converting back and forth #210
better slog support through special support in sinks ("SlogSink"): slogr: add SlogSink #211
context support (optional): RFC: slogr: add context support #213

Fixes: #171

pohly · 2023-08-03T11:54:35Z

slog_test.go

+}
+
+func ExampleToSlog() {
+	logger := logr.ToSlog(funcr.New(func(prefix, args string) {


I was thinking about adding slog support to funcr, but decided against it because:

here I want to test the code in slogHandler, which wouldn't be used if funcr itself supported slog

the handlers that come with slog provide similar functionality, so I don't see the need

However, klog and zapr definitely should get extended. I've started doing that for zapr, using the same interface for conversion that I am proposing here.

For zapr see go-logr/zapr#60

I don't object to impl libraries supporting both logr and slog, but I don't know why it's logr's responsibility to participate.

Because logr.ToSlog and log.FromSlog are using it to avoid glue code. slogr.New and slogr.NewHandler (your PR) don't, but I think they should if we go with that API.

This enables the use of the logr.Logger API on top of a slog.Handler. The other direction is also possible, but some information is lost. Instead, logr implementations should better get extended for usage as slog.Handler. Going back and forth between the two APIs is now part of logr.

pohly · 2023-08-03T15:26:59Z

The reasons for doing this in logr itself
a) easy access to the new API calls

This is mostly for convenience.

b) it enables a future logr extension where logr itself manages a global default logger which can be provided by either a slog.Handler or a logr.LogSink

This needs to be explored further before this PR gets merged.

My goal is to add a logr.Get(ctx context.Context) logr.Logger, logr.GetSlog(ctx context.Context) *slog.Logger, logr.GetSlogHandler(ctx context.Context) slog.Handler and corresponding set methods so that usage of glue code is as minimal as possible, i.e. the set methods store exactly what they get and convert only when needed. That conversion will depend on the code in this PR.

The alternative is to only have logr.Get(ctx context.Context) logr.Logger and logr.Set(logger logr.Logger) in logr itself, with conversion to and from slog being done elsewhere. With that approach, the code from this PR could be in a separate go-logr/slogr repo.

Yet another alternative would be to start with a separate repo and only move the code if needed. But this will cause work not just for us, but also others. The advantage would be that the API doesn't need to be exactly right immediately because a separate repo can start with v0.1.0

The motivation for having such a get function is to get rid of the klog dependency in modules like client-go. They need access to a global fallback logger because we don't require that all contexts in Kubernetes have a logger, so replacing the current klog.FromContext with logr.FromContextOrDiscard would cause log output to get dropped.

pohly · 2023-08-03T19:08:32Z

The argument about having to convert in logr holds also without a global default logger: the same situation occurs when code using both APIs share the same context. It would be nice to support NewContext -> SlogFromContext -> SlogNewContext -> FromContext. This has to use the same key for context.Value to ensure that the most recent logger gets retrieve, and the value then has to be converted depending on what the caller needs.

pohly · 2023-08-03T19:40:45Z

slog.go

+	}
+
+	return New(&slogSink{handler: handler})
+}


It would be good if FromSlog(ToSlog(...)) and vice versa returned the original logger. This currently works when the backend supports both APIs. But if not, we end up layering slogSink on top of slogHandler or vice versa.

Can be fixed with the "underlier" pattern.

I skipped over one detail: logr.Logger.level gets lost during conversion.

Suppose someone does this:

func foo(logger logr.Logger) { // The Info call could be in some other library which only uses slog. logr.ToSlog(logger).Info("hello") } func bar(logger logr.Logger) { foo(logger.V(4)) }

Should that info message then become a debug message (info - 4 = debug in slog)? I think the answer is yes.

This can be done in the slogHandler or by wrapping a real slog.Handler (modify record), but it makes the conversion code more complex because logr.Logger.level needs to be restored when going back from such a slog.Handler to a logr.Logger (FromSlog(ToSlog(logger.V(4)) == logger.V(4)).

The same key must be used to ensure that the most recent logger gets retrieved. Converting on retrieval has the advantage that clients that only use one API don't need conversion.

pohly · 2023-08-03T20:25:49Z

the same situation occurs when code using both APIs share the same context

I've pushed one commit adding support for that,

thockin · 2023-08-03T21:05:27Z

There's a lot going on in this PR that I don't quite see why. I'm reading now, but if we could break it up into "bare minimum bridge logic" (which is what my own PR offers - bare minimum) and "other stuff to maybe make nicer UX", it would help.

thockin

How little can we get away with?

I think our PRs differ mostly in the UX. Can we step back and decide what we want the outermost API to be?

User story 1) I have a slog.Logger and need to call code that uses logr.
User story 2) I have a logr.Logger and need to call code that uses slog.

I envisioned:

func myCode(log slog.Logger) {
    l := slogr.New(log.Handler())
    codeThatWantsLogr(l)
}

func myCode(log logr.Logger) {
    s := slog.New(slogr.NewHandler(log))
    codeThatWantsSlog(l)
}

I guess you envisioned:

func myCode(log slog.Logger) {
    l := logr.FromSlog(log)
    codeThatWantsLogr(l)
}

func myCode(log logr.Logger) {
    s := logr.ToSlog(log)
    codeThatWantsSlog(l)
}

Questions:

Do we want a slog dep in the logr package or in a logr/slogr package or in a new repo slogr ?
How much do we encapsulate. Yours is more complete than mine. Mine is a bit more transparent.
Do we really need the *Handler variants you have?

.github/workflows/tests.yaml

thockin · 2023-08-03T20:25:22Z

context_slog.go

+	"log/slog"
+)
+
+// This file contains the version of NewContext and FromContext which supports


I think I get what you are doing here, but I am not sure why.

slog doesn't include "from context" functions - are you just "augmenting" their API by doing it here?

Do we really need this, or can we say "Go doesn't want to support it, go bother them" ?

I think I get what you are doing here, but I am not sure why.

slog doesn't include "from context" functions - are you just "augmenting" their API by doing it here?

Yes, and because any interoperable API has to know about both (see below). That cannot be in slog.

Do we really need this, or can we say "Go doesn't want to support it, go bother them" ?

That ship pretty much has sailed now. Suppose slog.NewContext and slog.FromContext were added now. Then consider this (simplified - no error handling) example:

func usingLogr(ctx context.Context) { logger := logr.FromContext(ctx) logger.Info("hello") } func usingSlog(ctx context.Context) { logger := slog.FromContext(ctx) logger.With("slogKey", "slogValue") ctx = slog.NewContext(ctx, logger) usingLogr(ctx) } func main() { logger := zapr.NewLogger(...) ctx := logr.NewContext(context.Background(), logger) usingSlog(ctx) }

What we want here is that "slogKey": "slogValue" get added to the "hello" message. logr.FromContext can't achieve that.

It can look for a logger with its own key and call slog.FromContext. But the context has both and slog.FromContext cannot decide which one is more recent and thus should be used.

This PR avoids that by using the same key for all kinds of loggers.

But as soon as slog realizes this was the wrong decision, we're back to this problem, right?

My impression from the discussion was that the decision to not support passing via context is final.

thockin · 2023-08-03T21:07:00Z

slog.go

+
+// SlogImplementor is an interface that a logr.LogSink can implement
+// to support efficient logging through the slog.Logger API.
+type SlogImplementor interface {


I'm having a hard time really grasping why we want this

See other comments ("avoid glue code").

Can we maybe do this as 2 (or more) PRs?

Add trvially obvious bridge support with known gotchas.

Make changes to logr to make cotchas less.

Add optional interface indicating direct support for slog.

Context mania

We can definitely start with step 1.

Do you want to do that here on some experimental branch or in a separate repo? I'm leaning towards doing it here, in the main package, because I expect that we'll need that eventually. We just shouldn't merge it into "master" yet.

I'm less sure about the order of the next two steps. Solving some of these issues will be hard and take time. The end result will still be less efficient. It would be simpler to do step 3 first and enhance klog and zapr. Then Kubernetes will be ready to support packages using slog as API much sooner.

I just saw your comment below about context handling with the key defined in an internal package. That should work, so let me take back the "in the main package": let's start in this repo with "slogr" as package?

I'm OK to skip step 2 if we decide step 3 is the better answer.

This branch seems fine, and we can commit things and then revise, as long as we don't tag a release yet.

WRT which package - logr.ToSlog and logr.FromSlog are pleasant. I think a slogr package is better if the API is really parallel to funcr, zapr, etc - slogr.New(slog.Handler).

Maybe step 1 is to evaluate that difference.

Instead of rewriting the entire branch for this PR, I created a new one for step 1: #205

thockin · 2023-08-03T21:08:20Z

slog_test.go

+}
+
+func ExampleToSlog() {
+	logger := logr.ToSlog(funcr.New(func(prefix, args string) {


I don't object to impl libraries supporting both logr and slog, but I don't know why it's logr's responsibility to participate.

thockin · 2023-08-03T21:10:27Z

sloghandler.go

+	return l.sink.Enabled(levelFromSlog(level))
+}
+
+func (l *slogHandler) Handle(ctx context.Context, record slog.Record) error {


In all of these, ctx is unusued, so should be named _ ?

thockin · 2023-08-03T21:12:39Z

sloghandler.go

+)
+
+type slogHandler struct {
+	sink        LogSink


my impl chose to store the Logger rather than the LogSink. I'm not sure it's better, but I am curious why you chose Sink? I chose Logger because it felt easier. (FWIW, my impl of logr->slog first held a slog.Logger, but apparently that's not what slog wants us to do).

Mostly for symmetry: we are layering some high-level API on top of some low-level API. Doing the same here with LogSink as in slogSink with slog.Handler seemed appropriate.

I chose Logger because it felt easier.

Is it really? Using l.sink.Enabled/Info/Error below is trivial and avoids calling code that doesn't add any value.

logr.Logger is not a no-op, though.

logrLogger := logr.Discard() // nil LogSink slogLogger := logr.ToSlog() slogLogger.Info() // -> panic (I think?)

Similarly, Logger.WithCallDepth() does the LogSink interface test.

True, I need to handle a nil sink. I wasn't trying to do anything with call stack unwinding, so I didn't need that.

thockin · 2023-08-03T21:41:11Z

sloghandler.go

+	return &l
+}
+
+func (l slogHandler) WithGroup(name string) slog.Handler {


I see now what this is, and I am less enamored with it. I thought it was to accumulate Attrs into a "pseudo-struct" which would then fold into the parent Handler, but I see that's not the case.

e.g.

log := getMySlogger() log.WithGroup("grp").WithAttrs(slog.Int("a", 1), slog.Int("b", 2)) log.Info("The message", "arg", 31415) => {"msg": "The message", "grp": { "a": 1, "b": 2 }, "arg": 31415}`

But that's not it. then I thought it would at least assemble a struct and log it as such:

log := getMySlogger() log.WithGroup("grp").LogAttrs(lvl, "The message", slog.Int("a", 1), slog.Int("b", 2)) => {"msg": "The message", "grp": { "a": 1, "b": 2 }}`

But that doesn't seem right either, unless this adapter caches all the WithAttrs and then sends them all to logr when it is actually logged (which will break things like funcr's hooks).

So a key-prefix seems about as good as we can get. That said, using a period as the delimiter means we get JSON like { "the.key1": 1, "the.key2": 2} which is strictly VALID but seems to break jq:

$ echo '{ "a": "aval", "b.key": 1, "b.val": 2}' | jq . { "a": "aval", "b.key": 1, "b.val": 2 } $ echo '{ "a": "aval", "b.key": 1, "b.val": 2}' | jq .a "aval" $ echo '{ "a": "aval", "b.key": 1, "b.val": 2}' | jq .b null $ echo '{ "a": "aval", "b.key": 1, "b.val": 2}' | jq .b.key null echo '{ "a": "aval", "b.key": 1, "b.val": 2}' | jq '.["b.key"]' 1

I didn't find any other "special" character that doesn't also break jq, so either we use something like underscore or we just document this oddity. Or we let users pass in the group-delimiter string.

I thought it would at least assemble a struct and log it as such

That's indeed what the slog.JSONLogger does:

package main import ( "log/slog" "os" ) func main() { logger := slog.New(slog.NewJSONHandler(os.Stdout, nil)) logger.WithGroup("group").With("hello", "world").Info("ping") }

=>

{"time":"2023-08-04T08:33:43.56963767+02:00","level":"INFO","msg":"ping","group":{"hello":"world"}}

When wrapping zapr (the current one without slog support), I get instead:

{"level":"info","msg":"ping","group.hello":"world"}

With slog support there is at least a chance to implement WithGroup properly - but I haven't tried that yet (open TODO).

Once I found https://github.com/uber-go/zap/blob/v1.25.0/field.go#L334 it was trivial.

Now I get:

{"level":"info","msg":"ping","group":{"hello":"world"}}

How does that intersect with WithValues() ?

E.g.:

s := logr.ToSlog(myLogger) s.With("a", 1) // calls Handler.WithAttrs(), which calls logr WithValues("a", 1) s = s.WithGroup("g") s.With("b", 2) // calls Handler.WithAttrs(), which calls logr WithValues("g.b", 2) s.Info("msg", "c", 3) // calls Handler.Handle, which calls logr.Info("msg", "g.c", 3)

The only options I see are

Live with output "g.b": 2, "g.c": 3

don't use logrHandler under slog, use native slog support

accumulate calls to WithAttr(), so it becomes:

s := logr.ToSlog(myLogger) s.With("a", 1) // calls Handler.WithAttrs(), which calls logr WithValues("a", 1) s = s.WithGroup("g") s.With("b", 2) // calls Handler.WithAttrs(), which saves "b"=2 s.Info("msg", "c", 3) // calls Handler.Handle, which calls logr.Info("msg", "g", map[string]any{"b": 2, "c": 3})

teach logr to have a "group" construct.

I'm interested in this approach, but I think we can accept (0) until we do that. Fair?

#199

thockin · 2023-08-03T21:46:30Z

slogsink.go

+	l.callDepth = info.CallDepth
+}
+
+func (l *slogSink) WithCallDepth(depth int) LogSink {


in funcr I adopted the convention that methods which were going to clone the sink did:

func (sink slogSink) WithCallDepth(depth int) logr.LogSink { sink.depth += depth return &sink }

This saves 1 LOC and I couldn't tell if it had any other side-effects. I don't REALLY care but it seems unfortunate to have both styles in the same codebase.

Fine with me, let's do the same here.

thockin · 2023-08-03T21:48:50Z

slogsink.go

+
+func (l *slogSink) Info(level int, msg string, kvList ...interface{}) {
+	if l.prefix != "" {
+		msg = l.prefix + ": " + msg


In my PR I chose to track the "name" and report it as a distinct key-value pair ("logger":"my/logger/name") rather than mutating the user's message.

Do you have a reason to do it this way instead?

I also added the V level as a key, since slog obscures that:

func (sink slogSink) Info(level int, msg string, kvList ...interface{}) { args := make([]interface{}, 0, len(kvList)+4) if len(sink.name) != 0 { args = append(args, "logger", sink.name) } args = append(args, "vlevel", level) args = append(args, kvList...) sink.log(slog.Level(-level), msg, args...) }

Do you have a reason to do it this way instead?

Not a strong one, just a slight concern about adding more "special" keys. That also applies to "vlevel". What if some program is already using that for something else?

"err" for slogSink.Error has the same problem.

wrt special keys:

We could choose to "group" keys (we didn't in the past, but there's always v2 :). We still have to pick a name for the group. We could name-prefix keys (e.g. "logr/name") but it seems unfortunate to embed "logr" into the keyspace.

I don't like mutating the message. I agree that "err" as a special key is clunky, but we need SOME special keys. slog does too: https://pkg.go.dev/golang.org/x/exp/slog#JSONHandler.Handle

Unless we namespace all the user-provided keys. This also feels orthogonal to getting slog support in - I am not against changing this, but lets consider that across all the impls we support.

#198

I'm fine with using "logger" here.

thockin · 2023-08-03T21:54:22Z

slogsink.go

+}
+
+var _ LogSink = &slogSink{}
+var _ CallDepthLogSink = &slogSink{}


I implemented Underlier:

// Underlier exposes access to the underlying logging function. Since // callers only have a logr.Logger, they have to know which // implementation is in use, so this interface is less of an // abstraction and more of a way to test type conversion. type func (Underlier).GetUnderlying() invalid type GetUnderlying() slog.Handler } func (sink slogSink) GetUnderlying() slog.Handler { return sink.handler } var _ Underlier = &slogSink{}

thockin · 2023-08-03T22:06:59Z

slog.go

+
+func levelFromSlog(level slog.Level) int {
+	if level >= 0 {
+		// logr has no level lower than 0, so we have to truncate.


logr docs say:

"Negative V-levels have the same meaning as V(0)."

so you don't need to worry about this (minor point)

At some point I want to discuss with you whether V(-1) should be supported, though.

It think it is a valid use case to say "I want more output when calling this code here", which is someCode(logger.V(-1)). Right now we only support "I want less output": someCode(logger.V(1)). Ironically, the latter use case is the one that Jordan was concerned about because when seeing logger.V(5).Info in someCode it's not obvious that running the binary with -v=5 won't produce that output. That's not a problem with someCode(logger.V(-1)) and it was a use case that scheduler folks wanted ("produce more output when scheduling a specific pod").

That slog supports "more important than INFO" (= slog.LevelWarn = 4) and "less important than INFO" (= slog.LevelDebug = -4) while logr only supports "less important than INFO (= V(4)) is another aspect to consider. I understand that this was intentional, but it keeps coming up.

I have not heard that argument, and I am skeptical of it.

Every package is the center of their own universe, and thinks they know what's important. logr V(0) means "always log", unless somebody upstream from you has decided that you are less important than you think you are. I'm not sure we should be giving callsites the ability to override that.

I don't object to leaving this, other than "less is more", but simply negating the level seems correct-ish anyway. If you somehow had a V(-1) logr call it would become INFO+1 in slog.

Anyway, that's orthogonal to this PR. I'd prefer we strip this one of anything speculative, get the bare basics merged, and then see how to do better

Agreed. I got carried away when you mentioned negative levels 😅

thockin · 2023-08-03T22:12:47Z

sloghandler.go

+	return l.sink.Enabled(levelFromSlog(level))
+}
+
+func (l *slogHandler) Handle(ctx context.Context, record slog.Record) error {


We need to document somewhere that the passed-in timestamp is ignored, and any logr.LogSink which logs the time is going to produce its own timestamp.

The README has a list of drawbacks that come from using glue code for "logr on slog" - this is another one which I need to add.

thockin · 2023-08-03T22:15:18Z

sloghandler.go

+	return l.sink.Enabled(levelFromSlog(level))
+}
+
+func (l *slogHandler) Handle(ctx context.Context, record slog.Record) error {


Somewhere we need to handle caller info. My PR gets it right by hardcoding a depth, which I don't think slog will want to guarantee.

Maybe we need to call Callers() again and walk back until I find the PC they gave us, and add that many frames to the logr depth?

My PR gets it right by hardcoding a depth, which I don't think slog will want to guarantee.

Only if the code using the handler is using slog.Logger. We can't assume that, the code might also use something else with different offsets.

Maybe we need to call Callers() again and walk back until I find the PC they gave us, and add that many frames to the logr depth?

Urgh. That probably works in most usages, but not when the record was produced in one goroutine and then gets logged somewhere else entirely.

thockin

Also we need examples and slog test and stuff, but that's after we agree on design

pohly · 2023-08-04T05:54:53Z

How little can we get away with?

I think our PRs differ mostly in the UX.

Not just that. Avoiding glue code (slogHandler, slogSink in my PR) when a backend supports both is important for high-quality logging. It is possible to write such glue code, but there are conceptual differences that simply cannot be handled. The "logr on slog" case is kind of okay, but "slog on logr" is pretty bad. That's why my PR has this whole conversion support.

Can we step back and decide what we want the outermost API to be?

I think that follows from the conceptual question above: is the focus more on conversion (back and forth) or more on "I just want a new logger"? Depending on that one API may be more suitable than the other.

Do we want a slog dep in the logr package or in a logr/slogr package or in a new repo slogr ?

My main argument at this point for having it in logr is that context support then works better - see the new(ish) "support slog.Logger and slog.Handler in context" commit that I added later yesterday.

How much do we encapsulate. Yours is more complete than mine. Mine is a bit more transparent.

I'm not sure what you mean with encapsulate.

Do we really need the *Handler variants you have?

Not sure. slog has two logging APIs (slog.Logger and slog.LogSink) and it has been said repeatedly that it's fine for code to use slog.LogSink directly for cases where the simpler slog.Logger isn't suitable. Therefore I can imagine that there will be code which doesn't have a slog.Logger instance. If we then only offer support for slog.Logger, such code must first create one with slog.New, which causes an additional allocation. Not a big deal when it only occurs once, but what if it needs to be done for every log call even when no log entry gets emitted?

thockin · 2023-08-04T17:12:46Z

Can we step back and decide what we want the outermost API to be?

I think that follows from the conceptual question above: is the focus more on conversion (back and forth) or more on "I just want a new logger"? Depending on that one API may be more suitable than the other.

I think you have looked at it longer than me, so I need some time to "catch
up". I will likely end up where you are, but I'd prefer to do it
incrementally.

Do we want a slog dep in the logr package or in a logr/slogr package or in a new repo slogr ?

My main argument at this point for having it in logr is that context support then works better - see the new(ish) "support slog.Logger and slog.Handler in context" commit that I added later yesterday.

Hypothetically, could we do something like:

logr/internal/ctximpl/context.go:

package ctximpl

// ContextKey is how we find loggers in a context.Context.
type ContextKey struct{}

// NotFoundError exists to carry an IsNotFound method.
type NotFoundError struct{}

func (NotFoundError) Error() string {
	return "no logger was present"
}

func (NotFoundError) IsNotFound() bool {
	return true
}

logr/logr.go:

import "github.com/go-logr/internal/ctximpl"

type contextKey = ctximpl.ContextKey

// unchanged
func FromContext(ctx context.Context) (Logger, error) {

// unchanged
func FromContextOrDiscard(ctx context.Context) Logger {

// unchanged
func NewContext(ctx context.Context, logger Logger) context.Context {

logr/slogr/context.go:

import "github.com/go-logr/internal/ctximpl"

type contextKey = ctximpl.ContextKey

// any bridge stuff we want

Basically, the logr package is super lightweight - I don't think we should
impose a transitive dep to slog on libs that just use logr.Logger.

How much do we encapsulate. Yours is more complete than mine. Mine is a bit more transparent.

I'm not sure what you mean with encapsulate.

How much of the complexity of the dual-universe do we try to make nicer (all
the context stuff is a good example) vs letting it exist (for now)?

Do we really need the *Handler variants you have?

Not sure. slog has two logging APIs (slog.Logger and slog.LogSink) and it has been said repeatedly that it's fine for code to use slog.LogSink directly for cases where the simpler slog.Logger isn't suitable. Therefore I can imagine that there will be code which doesn't have a slog.Logger instance. If we then only offer support for slog.Logger, such code must first create one with slog.New, which causes an additional allocation. Not a big deal when it only occurs once, but what if it needs to be done for every log call even when no log entry gets emitted?

I can imagine a lot of things, but I don't think we should speculate without
some real use-cases. Let's be ruthlessly minimalist and see how far that takes
us. If someone show up with a case where this fails, I do not object to making
things better, but then we will know WHY.

pohly · 2023-08-04T17:51:17Z

Hypothetically, could we do something like:

logr/internal/ctximpl/context.go:

That looks doable.

I can imagine a lot of things, but I don't think we should speculate without
some real use-cases. Let's be ruthlessly minimalist and see how far that takes
us.

Fair enough. So let's only support slog.Logger for now, based on the assumption that more code will need and use that.

pohly · 2023-08-04T18:10:56Z

logr/logr.go:
// unchanged
FromContext(ctx context.Context) (Logger, error) {

I need to point out one implication: because this code remains unchanged, the value must be a Logger and thus slogr.NewContext and slogr.FromContext must always do conversions.

thockin · 2023-08-04T18:36:18Z

re Context - I don't yet have a clear metal model, so let's stack that for after the baseline discussion/bridge logic.

pohly · 2023-11-21T07:19:16Z

Most of the functionality was merged into the separate slogr package, except for context support - see #234.

github-actions bot assigned pohly and thockin Aug 3, 2023

pohly commented Aug 3, 2023

View reviewed changes

pohly force-pushed the slog branch from fd0ee7d to 627d321 Compare August 3, 2023 12:03

pohly added 2 commits August 3, 2023 14:07

test with recent Go

e40bcc0

pohly force-pushed the slog branch from 627d321 to b142419 Compare August 3, 2023 12:07

pohly mentioned this pull request Aug 3, 2023

support slog go-logr/zapr#60

Merged

pohly mentioned this pull request Aug 3, 2023

WIP: add slogr #195

Closed

pohly commented Aug 3, 2023

View reviewed changes

support slog.Logger and slog.Handler in context

ddaa1ac

The same key must be used to ensure that the most recent logger gets retrieved. Converting on retrieval has the advantage that clients that only use one API don't need conversion.

thockin reviewed Aug 3, 2023

View reviewed changes

This was referenced Aug 4, 2023

Consider changing how keys are namespaced #198

Open

Consider a "group" construct to match slog #199

Open

Bump min Go version to at least 18? #202

Closed

pohly changed the title ~~slog support~~ WIP: slog support Aug 5, 2023

pohly mentioned this pull request Aug 7, 2023

slogr: add glue code for logging to slog.Handler and with slog.Logger #205

Merged

pohly mentioned this pull request Aug 27, 2023

RFC: slogr: add context support #213

Closed

pohly mentioned this pull request Oct 24, 2023

output: handle WithName like zapr does kubernetes/klog#391

Merged

pohly closed this Nov 21, 2023

WIP: slog support #196

WIP: slog support #196

Conversation

pohly commented Aug 3, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pohly commented Aug 3, 2023

pohly commented Aug 3, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pohly commented Aug 3, 2023

thockin commented Aug 3, 2023

thockin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pohly Aug 4, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thockin Aug 4, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thockin Aug 4, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thockin left a comment

Choose a reason for hiding this comment

pohly commented Aug 4, 2023

thockin commented Aug 4, 2023

pohly commented Aug 4, 2023

pohly commented Aug 4, 2023

thockin commented Aug 4, 2023

pohly commented Nov 21, 2023

pohly commented Aug 3, 2023 •

edited

pohly Aug 4, 2023 •

edited

thockin Aug 4, 2023 •

edited

thockin Aug 4, 2023 •

edited