github.com/golang/glog: Using replacement flag packages

278 views
Skip to first unread message

Ivan Vučica

unread,
Jun 25, 2017, 6:31:39 PM6/25/17
to golang-nuts
Hello,

Since glog's readme recommends firing off an email to golang-nuts to
report possible issues, here I go.

I really like the idea of specifying flags in flagfiles and
environment variables. This Go package seems to let me do that, while
staying pretty much API-compatible with the standard flag package:
github.com/namsral/flag

However, if I start using it as a replacement for "flag" package, the
program (naturally) only recognizes flags specified using namsral's
flag package. This means that the flags defined in the glog package
are not visible to namsral's package, and thus are not visible to the
user.

Since variables backing the glog flags are not part of the public
interface, I can't, really, write a nice wrapper. Instead I could
write a wrapper that reads the values from namsral/flags-created
variables, and uses flag.Set() to set them into Go's flag package, and
then calls Go's flag.Parse().

That feels bad. Does anyone have any suggestions on alternative
approaches? Could the variables backing the flags be exposed, so I can
do my own calls to flag.BoolVar()/flag.Var()?

Would it make sense to extend Go's flag package to use the environment
and flagfiles in addition to just command line arguments?

Tong Sun

unread,
Jun 26, 2017, 11:21:45 AM6/26/17
to golang-nuts
> I really like the idea of specifying flags in flagfiles and environment variables. 

For using environment variables with flags, take a look at 
which has not extra dependencies but the go native flag pkg. 

All you need is to provide a file like this:

For using flagfiles and environment variables, take a look at 

Options:

  -h, --help              display help information
  -c, --config[=1.json]   config
  -H, --host[=$HOST]      host addr
  -p, --port              listening port
If you like to go down that route, take a further look at 

ivu...@gmail.com

unread,
Jun 26, 2017, 6:12:29 PM6/26/17
to golang-nuts
On Monday, June 26, 2017 at 4:21:45 PM UTC+1, Tong Sun wrote:
For using environment variables with flags, take a look at 
which has not extra dependencies but the go native flag pkg. 

All you need is to provide a file like this:

This is quite interesting. It does partially address the issue, in that it will no longer break flags specified in other packages. In that regard, it comes quite close to solving my immediate issue.

On the other hand, it will still support only flags explicitly defined in the main project; except in this case, instead of switching to a drop-in replacement, I'd be switching to a generated block of code that happens to use the flag package.

Maybe it'd be easier to see where I'll end up with an inconsistency if I explained what I'm trying to use and what broke: I like using github.com/golang/glog for logging, and it happens to specify important flags such as 'logtostderr', 'alsologtostderr' and 'v'.

Clearly, with this solution at least glog won't be isolated and unable to see any of the flags (unlike with the package I quoted), but unless I write the wrapper similar to the one I could write for namsral's package, it's also going to be inconsistent by not handling glog's flags. If I decide I care about this consistency, then I'm then sort-of back where I started from.

Finally, I'm also not super-thrilled about adding extra code generation beyond protobuf code and gRPC stubs.
 

For using flagfiles and environment variables, take a look at 

Options:

  -h, --help              display help information
  -c, --config[=1.json]   config
  -H, --host[=$HOST]      host addr
  -p, --port              listening port
If you like to go down that route, take a further look at 

This is also interesting, but it switches me to a completely new way of processing CLI arguments (and I'm not sure that it preserves compatibility with stock flags package). While this is interesting for writing CLIs, I feel like it adds too much complication for server software.
Reply all
Reply to author
Forward
0 new messages