go-sdk icon indicating copy to clipboard operation
go-sdk copied to clipboard

chore: replaced with dapr-kit logger

Open sadath-12 opened this issue 1 year ago • 8 comments

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

sadath-12 avatar Jan 03 '24 05:01 sadath-12

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.

codecov[bot] avatar Jan 03 '24 05:01 codecov[bot]

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")

sadath-12 avatar Jan 09 '24 08:01 sadath-12

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")

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 avatar Jan 15 '24 11:01 mikeee

@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

sadath-12 avatar Jan 16 '24 12:01 sadath-12

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.

mikeee avatar Jan 16 '24 13:01 mikeee

ok so shall we do like for example logClient in the client package

sadath-12 avatar Jan 16 '24 14:01 sadath-12

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

mikeee avatar Feb 21 '24 10:02 mikeee

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

qustavo avatar Feb 21 '24 10:02 qustavo