dependency on glog (via txtpbfmt) adds some flags to a program's std flag list

[knieriem]

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.

[ChrisHines]

Another approach is to replace glog with an API equivalent that redirects the glog calls to something else and removes the global flags added by glog as a result. I've seen several packages that replace glog with shims for different specific logging packages. https://github.com/slok/noglog shows how the technique works in a general way.

[knieriem]

Thanks for this hint. Adding

 replace github.com/golang/glog => github.com/slok/noglog v0.2.0 

to go.mod appears to be sufficient. There remains a problem when running go mod tidy, which fails because the module directive of noglog's go.mod file does not match glog's (as required by the modules reference), but this could be fixed.

[myitcv]

Using a replace directive is, however, only a temporary solution, because it creates downstream problems of its own. Hence why this needs to be fixed upstream; I wouldn't want the CUE project to be offering this as a permanent fix suggestion to users if the "fix" creates more problems for them.

[myitcv]

This seems rather unfortunate to put it mildly, and something we should attempt to fix via a PR to the github.com/protocolbuffers/txtpbfmt module. Thanks for raising, @knieriem - I will create an issue tracking that off the back of this discussion.

[gurjeet]

The good first issue label made this problem look deceptively simple; false advertising :-)

But I have take a crack at solving this problem, so if the fix is merged, all users of the glog package will be able to override these flags at build time. See golang/glog#54