slog context support#237
Conversation
thockin
left a comment
There was a problem hiding this comment.
This isn't horrible, to me, but it seems like one day slog will decide to add context support and then we'll have to do it all again.
| // | ||
| // The logr verbosity level is mapped to slog levels such that V(0) becomes | ||
| // slog.LevelInfo and V(4) becomes slog.LevelDebug. | ||
| func NewLogr(handler slog.Handler) Logger { |
There was a problem hiding this comment.
So we have logr.New(logr.LogSink) and logr.NewLogr(slog.Handler) ? Eww.
NewFromSlogHandler() ?
There was a problem hiding this comment.
I hadn't thought much about the names. I agree that it makes sense to reconsider, now that they are being used with logr as package selector instead of slogr.
I'm fine with NewFromSlogHandler.
There was a problem hiding this comment.
Renamed in a separate commit, to have an explanation for the reason in the commit history.
I also restored slogr/slogr_test.go because that has an example and it's worth testing the code there. It doesn't do much, but better safe than sorry...
Very unlikely. |
|
I suspect that Context methods will be reconsidered as people adopt slog and find that to be egregiously absent. It was contentious among vocal early-adopters. It won't be contentious among the larger population (I think). |
4482fc7 to
277269c
Compare
|
I've pushed an update:
|
| Interoperability goes both ways, using the `logr.Logger` API with a `slog.Handler` | ||
| and using the `slog.Logger` API with a `logr.LogSink`. [slogr](./slogr) provides `NewLogr` and | ||
| `NewSlogHandler` API calls to convert between a `logr.Logger` and a `slog.Handler`. | ||
| and using the `slog.Logger` API with a `logr.LogSink`. [slogr](./slogr) provides `NewLogr` (= `logr.NewFromSlogHandler`) and |
There was a problem hiding this comment.
If this effectively replaces slogr, then we should just document the logr APIs here, not slogr.
There was a problem hiding this comment.
I wasn't sure whether we'd want to deprecate slogr - it just got added 🥵
But we can also do that, no strong opinion from me about it.
There was a problem hiding this comment.
I don't love having two equivaent ways of saying the same thng which are both "suported". Deprecated doesn't mean gone, just "look here instead". IMO
| // slog.LevelInfo and V(4) becomes slog.LevelDebug. | ||
| // | ||
| // NewLogr is identical to [logr.NewFromSlogHandler]. Either of these can | ||
| // be used. |
There was a problem hiding this comment.
Should these be Deprecated: Use logr.NewFromSlogHandler instead ?
There was a problem hiding this comment.
We could also kill off all the duplicate docs that way - users just go read the logr version.
There was a problem hiding this comment.
The duplicated docs are indeed annoying. I'm leaning towards simply deprecating slogr now.
| // slog.New(NewSlogHandler(logger.V(4))).Info(...) -> logger.GetSink().Info(level=4, ...) | ||
| // | ||
| // NewSlogHandler is identical to [logr.NewSlogHandler]. Either of these can | ||
| // be used. |
There was a problem hiding this comment.
same above re: Deprecated and var
| // level=DEBUG msg="with values, verbosity and name" x=1 y=2 str=abc logger=foo/bar | ||
| } | ||
|
|
||
| func ExampleNewSlogLogger() { |
There was a problem hiding this comment.
Should this be ExampleNewSlogHandler ?
| } | ||
|
|
||
| func ExampleNew() { | ||
| logger := logr.NewFromSlogHandler(slog.NewTextHandler(os.Stdout, debugWithoutTime)) |
There was a problem hiding this comment.
can we name the var logrLogger ?
| Verbosity: 10, | ||
| }) | ||
|
|
||
| logger := slog.New(logr.NewSlogHandler(funcrLogger)) |
There was a problem hiding this comment.
can we name the var slogLogger ?
| } | ||
| } | ||
|
|
||
| // FromContext returns a slog.Logger from ctx or nil if no such Logger is found. |
There was a problem hiding this comment.
comment doesn't match code wrt the name
| } | ||
|
|
||
| // FromContext returns a slog.Logger from ctx or nil if no such Logger is found. | ||
| func SlogLoggerFromContext(ctx context.Context) *slog.Logger { |
There was a problem hiding this comment.
can I argue for FromContextAsSlogLogger so the FromContext and NewContext prefixes survive?
|
ICYMI - there was no new push :) |
I wanted to revise the documentation part first regarding deprecation, but I am not going to get to that this evening anymore, so I pushed what I have just now. The next update will be tomorrow. |
9ac9983 to
ca4a15b
Compare
|
I've updated the documentation and removed the |
| provides additional support code for this approach. It also contains wrappers | ||
| for the context functions in logr, so developers who prefer to not use the logr | ||
| APIs directly can use those instead and the resulting code will still be | ||
| interoperable with logr. |
This is necessary to give the context handling functions access to the slogr functionality. Functions get renamed to match names in the main package where needed. The slogr package is now deprecated, but continues to be supported as part of the logr v1 API by keeping all exported items as wrappers or aliases for the main package.
Conversion is done on demand. A program which uses either slog or logr for logging remains as efficient as before. What is less efficient is storing a logger of one type and then retrieving it as the other. Ideally, reusable packages should avoid using a slog.Logger and prefer logr.Logger instead when retrieving a logger from a context. There is a significant amount of packages which already work that way (Kubernetes and related packages), while storing and retrieving a logr.Logger is new and not done anywhere yet. Emulating existing behavior ensures better performance.
ca4a15b to
f1edf4f
Compare
|
New update pushed. I also found a left-over |
|
LGTM - hold for @veqryn to take a look? |
|
@pohly @thockin Could I get your eyes on this pr please: veqryn/slog-context#1 |
| } | ||
| return handler | ||
| // Deprecated: use [logr.ToSlogHandler] instead. | ||
| func ToSlogHandler(logger logr.Logger) slog.Handler { |
There was a problem hiding this comment.
Argh!
I messed up some global search/replace and renamed NewSlogHandler to ToSlogHandler although here we have to keep the old name.
Found when updating logr in klog. Will prepare a fix.
Conversion is done on demand. A program which uses either slog or logr for
logging remains as efficient as before. What is less efficient is storing a
logger of one type and then retrieving it as the other.
Ideally, reusable packages should avoid using a slog.Logger and prefer
logr.Logger instead when retrieving a logger from a context. There is a
significant amount of packages which already work that way (Kubernetes and
related packages), while storing and retrieving a slog.Logger is new and not
done anywhere yet. Emulating existing behavior ensures better performance.
To enable on demand conversion, the slogr implementation must be moved
into the main package.
Related-to: #234