-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pluggable logger #22
Pluggable logger #22
Conversation
Codecov Report
@@ Coverage Diff @@
## master #22 +/- ##
==========================================
+ Coverage 75.44% 75.89% +0.44%
==========================================
Files 12 13 +1
Lines 900 925 +25
==========================================
+ Hits 679 702 +23
- Misses 154 155 +1
- Partials 67 68 +1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Now GFS3 has it's pluggable logger!
ups. I guess my conflict resolution broke it ;-) and I have to get into a meeting marathon now. Will fix later >.< |
Oops, totally my fault, I didn't consider the interaction between the two PRs properly. I've fixed it up now, the test should pass. Sorry 'bout that. I hope the meetings are swift, productive and focused! 😄 |
Here's a refreshingly simple one! A couple of the projects I'm integrating gofakes3 with use different loggers to the standard library's log. I've got a useful little bit of copy-pasta for situations like this which I've popped in to this PR (
log.go
). It lets you swap the log out and adapt whatever your project happens to be using easily, and fall back on the standard library's logger even more easily. The CLI tool and tester should both still work exactly as before: the CLI will still log to console, and the tester will still redirect the log to a file. Using gofakes3 directly will no longer generate log output by default though: you have to opt in to the old behaviour usinggofakes3.WithGlobalLog()
.Go 2 will hopefully convert log.Logger to an interface, which would obviate the need for all this if log library authors get on board and implement it, but we're not there yet unfortunately: golang/go#13182