-
Notifications
You must be signed in to change notification settings - Fork 19
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
Please remove the hard dependency on glog #70
Comments
Hey Daniel! 👋 Agreed on all points. For historical context: we needed to get a number of ducks in a row for the initial open-sourcing of txtpbfmt, and doing something better than just swapping our internal Would you be willing to send a pull request which implements the interface you suggested? cc me on it, and we can get this improved. Thanks |
Oh, I wasn't aware you were involved :) I can certainly send a quick PR. |
Hi, I was wondering if there is an on going fix. As a cue user, I was quite annoyed to see the glog flags poping in my binary. |
Sending the PR is the fix. AFAICT, there was no PR yet |
Thanks for the pings - I completely forgot about this. I can send the PR today. |
As I was working on my patch for protocolbuffers#70, I was wondering if we really needed a logger interface with both Infof and Errorf. After all, a library should report its errors as values, not via a logger. Turns out it's relatively straightforward to do so. All functions that used to call log.Errorf are themselves called from top-level APIs which are able to return an error, so we just need to thread them. One special case is getMetaCommentStringValues, which used to report each error and continue rather than stop. We currently do not have an idiomatic way to report multiple errors at once, so return the first error for now. In the future, we could use https://go.dev/issue/53435. Updates protocolbuffers#70.
ooh I was going to do it as well haha. Well thank you for doing it @mvdan ! |
As I was working on my patch for protocolbuffers#70, I was wondering if we really needed a logger interface with both Infof and Errorf. After all, a library should report its errors as values, not via a logger. Turns out it's relatively straightforward to do so. All functions that used to call log.Errorf are themselves called from top-level APIs which are able to return an error, so we just need to thread them. One special case is getMetaCommentStringValues, which used to report each error and continue rather than stop. We currently do not have an idiomatic way to report multiple errors at once, so return the first error for now. In the future, we could use https://go.dev/issue/53435. Updates protocolbuffers#70.
All calls go through a logger in the config. The logger may be nil, so we check that it's non-nil everywhere. We want the conditional in every location, as otherwise we would evaluate all the format arguments even when logging is disabled. Some of them are relatively expensive, like strings.Join. We also keep the behavior in cmd/txtpbfmt unchanged. Calls to Errorf still end up going to glog.Errorf, and calls to Infof still end up going to glog.V(2).Infof. Fixes protocolbuffers#70.
All calls go through a logger in the config. The logger may be nil, so we check that it's non-nil everywhere. We also keep the behavior in cmd/txtpbfmt unchanged. Calls to Errorf still end up going to glog.Errorf, and calls to Infof still end up going to glog.V(2).Infof. Fixes protocolbuffers#70.
All calls go through a logger in the config. The logger may be nil, so we check that it's non-nil everywhere. We also keep the behavior in cmd/txtpbfmt unchanged. Calls to Errorf still end up going to glog.Errorf, and calls to Infof still end up going to glog.V(2).Infof. Note that the library used the boolean value of glog.V(2) to tell whether the "info" log level was enabled or not. When disabled, this allowed us to not compute some log arguments, such as calls to strings.Join or string copies. Since we can't assume an interface to be of boolean type, add an extra InfoLevel method to perform the same duty. Fixes protocolbuffers#70.
As I was working on my patch for #70, I was wondering if we really needed a logger interface with both Infof and Errorf. After all, a library should report its errors as values, not via a logger. Turns out it's relatively straightforward to do so. All functions that used to call log.Errorf are themselves called from top-level APIs which are able to return an error, so we just need to thread them. One special case is getMetaCommentStringValues, which used to report each error and continue rather than stop. We currently do not have an idiomatic way to report multiple errors at once, so return the first error for now. In the future, we could use https://go.dev/issue/53435. Updates #70.
Second take, as the first merge was undone by a bot. As I was working on my patch for protocolbuffers#70, I was wondering if we really needed a logger interface with both Infof and Errorf. After all, a library should report its errors as values, not via a logger. Turns out it's relatively straightforward to do so. All functions that used to call log.Errorf are themselves called from top-level APIs which are able to return an error, so we just need to thread them. One special case is getMetaCommentStringValues, which used to report each error and continue rather than stop. We currently do not have an idiomatic way to report multiple errors at once, so return the first error for now. In the future, we could use https://go.dev/issue/53435. Updates protocolbuffers#70.
The parser imports https://github.com/golang/glog directly, for calls such as:
txtpbfmt/parser/parser.go
Line 392 in fc78c76
txtpbfmt/parser/parser.go
Line 989 in fc78c76
It's understandable to want to have some verbose logging, but I think it's a bad idea for a "pure" Go library such as a parser to make direct calls to a logging library:
glog
as part of their build and binary, even if they don't want nor need any logging.I think the best and simplest API fix would be to declare a logging interface and use it, such as:
One could also argue that error logs should be returned as error values instead, but I'm not very familiar with how the glog API is designed in detail.
I'm filing this because I'm the maintainer of a relatively large open source program where we use and ipmort txtpbfmt, but we pull glog indirectly too, which unfortunately affects us in multiple ways (e.g. cue-lang/cue#1199, but also binary size etc).
The text was updated successfully, but these errors were encountered: