encoding/protobuf: dependency on glog adds some flags to a program's std flag list #1199
Description
Originally posted by knieriem August 8, 2021 in #1196
When upgrading a program importing a package from cue v0.3.0-beta* to v0.4.0 I noted that CUE's new dependency github.com/protocolbuffers/txtpbfmt adds another dependency, github.com/golang/glog (leveled execution logs for Go). go mod why lists, for instance:
cuelang.org/go/cue/load
cuelang.org/go/internal/encoding
cuelang.org/go/encoding/protobuf/textproto
github.com/protocolbuffers/txtpbfmt/parser
github.com/golang/glog
Glog, as a package, in its init function defines some command line flags using Go's standard flag package:
-alsologtostderr
-log_backtrace_at value
-log_dir string
-logtostderr
-stderrthreshold value
-v value
-vmodule value
As a result, any program importing, for example, cuelang.org/go/cue/load will automatically inherit these flags. In my program, which makes use of the standard flag package, I had been defining an own flag.Uint("v", 0, "verbosity level").
With cue v0.4.0 I'm getting a panic: ... flag redefined: v error now.
Since the cue program itself is using cobra+pflag, this effect is not visible when using cue itself, since flags defined using Go's standard flag package are ignored then.
An old thread at golang-nuts, glog and testing flag "pollution" mentions a workaround: defining one's own flag.FlagSet instead of using the default flag.CommandLine. But this also means, that all flags defined by a program's internal packages using e.g. flag.Bool must be adapted to the new FlagSet.
An alternative to this workaround would be to make textproto depend on a modified txtpbfmt that does not depend on glog. I think for my use-case I will apply the method described in that golang-nuts thread.