go-sdk
go-sdk copied to clipboard
chore: replaced with dapr-kit logger
Description
Currently we use log
package for logging whereas we have our own logger available at github.com/dapr/kit/logger
which we should make use it
Issue reference
Please reference the issue this PR will close: #[issue number]
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:
- [x] Code compiles correctly
- [x] Created/updated tests
- [] Extended the documentation
Codecov Report
Attention: 2 lines
in your changes are missing coverage. Please review.
Comparison is base (
c8f3533
) 70.26% compared to head (8d5806a
) 70.08%.
:exclamation: Current head 8d5806a differs from pull request most recent head a2d551d. Consider uploading reports for the commit a2d551d to get more accurate results
Files | Patch % | Lines |
---|---|---|
actor/manager/container.go | 0.00% | 1 Missing :warning: |
client/client.go | 80.00% | 1 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## main #491 +/- ##
==========================================
- Coverage 70.26% 70.08% -0.19%
==========================================
Files 35 35
Lines 2859 2841 -18
==========================================
- Hits 2009 1991 -18
Misses 738 738
Partials 112 112
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I would like to see the logger name kept, we shouldn't have unnecessary package name collisions especially with the standard library.
The service grpc and http documentation should use the standard library / be open to the user.
you mean to change the name of log to something elsevar log = logger.NewLogger("dapr.actor.manager")
I would like to see the logger name kept, we shouldn't have unnecessary package name collisions especially with the standard library. The service grpc and http documentation should use the standard library / be open to the user.
you mean to change the name of log to something else
var log = logger.NewLogger("dapr.actor.manager")
Yep, I just think it looks cleaner than using a naming convention that clashes with the standard library where it doesn't interface cleanly.
@mikeee can we think in this way .. because of same name I was able to quickly migrate to new liberary . so maybe that's a plus point over using different names . just thinkering for this let me know if you agree or else ill change
This is a breaking change whichever way it's looked at. Sure you may have some functions that cross-over but I believe there should be no shadowing of the log package (or anything else in the standard library) unless it retains the same interfaces.
ok so shall we do like for example logClient
in the client package
I'm not entirely sure about using kit/logger
in a user written application would be preferable.
@qustavo what are your thoughts about this change?
The recent change made by @qustavo allows for a user-specified logger as part of the client created, perhaps this addresses the need to migrate entirely to kit/logger
and not change the expected output/functionality of the current logging implementation
I'm not entirely sure about using
kit/logger
in a user written application would be preferable. @qustavo what are your thoughts about this change?
From what I can see, the logging requirements for the sdk are minimal. We log.Print[f,ln]
and log.Fatal[f]
and the current logging implementation is sufficient. That being said, we could support a custom logger injection if SetLogger
accepted an interface rather than a concrete implementation, so that you can bring your own logger, although that might be overkill.
In general I'd wait until the need for a more elaborated logging strategy is needed.
@sadath-12 is there a use case for using kit/logger
that I'm overlooking?
https://github.com/dapr/go-sdk/blob/7e5ee73aa842660f3bb2c958947d1faa3f665022/client/client.go#L68