Use glog with alternate flags library?

[Joe Beda]

Hi all,

We are using glog extensively in Kubernetes.  However, we are also starting to use cobra commander (github.com/spf13/cobra) for our command line tools.  Cobra commander uses a POSIX flag compatible library (github.com/spf13/pflags).

I'm looking at switching the rest of Kubernetes over to using pflags instead of the standard golang flags library.  I see this as a usability win for our users as the golang flag variants have caused a small amount confusion.

The problem is that glog is locked down to the point that I don't see an easy way to adapt it to pflags.  Would you folks be open to making it more amenable to a different flag library?  Ideas on how best to do this?

Thanks,

Joe

[Rob Pike]

Flags are threaded through the whole package. Honestly your best bet might be to fork the package.

-rob

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jian Zhen]

I ran into the same issue using cobra and glog as well. Thought about doing something similar but realized that I also use glog a ton in _test.go files. So if I change glog to use pflags, then I won’t be able to supply the glog flags in a “go test” command. 

Not sure what the right solution is if both scenarios are needed…

[Tamás Gulácsi]

I've done the following: create a package, which imports blog, then move its registered flags into another FlagSet. This is against blog "polluting" the default FlagSet.

For cobra, I'm just calling flag.Parse on the remaining args after pflag parsed it.

Yeah, I know this is a hack, but glog is locked down, and a very nice lib, so I don't want to miss its changes, but don't want to manage that by myself only.

Want a "pglog"?

[Joe Beda]

I was able to make this work by wrapping the flag.Value structs with a new struct that implements the pflag.Value interface.

See my PR here:

https://github.com/GoogleCloudPlatform/kubernetes/pull/3342/files

Thanks,

Joe

[Steve Francia]

Joe & Jian,

I'm totally open to any improvements that need to happen here, especially ones that make it easier to integrate. Personally I feel that the pflags library is an improvement over the standard flags one, but also needs work. I'd prefer an interface driven library, but haven't had time to build one out yet. 

Appreciate your interest in cobra. Happy to help anywhere there is need.

--
Steve Francia
http://stevefrancia.com
http://spf13.com
http://twitter.com/spf13

[Jian Zhen]

Thanks Steve.

Cobra’s great. It’s my default go-to package for cmdline utils now. Thanks for the great package.

Jian

[Frank Schröder]

Looks like an interesting project. Are the POSIX flags necessary to build the functionality or are they just a convenience? Given that the standard flags lib is used in other places this should cause friction and fragmentation since now users have to choose which lib to use. I don't really care for the one or the other but I don't want to have both. I've got a codebase of about 40 tools and servers and we're using flags everywhere. This also applies to the scripts that call the tools since they know about -http and not --http. Mixing both libs is a non-starter for us although I'd like to build tools with your lib. 

Having said that: Can't you make the flag lib which is used optional?

Frank