support for env only flags

[cppforlife]

i really like flag abstraction that go-flags enforces (input flowing one way). some flags may contain sensitive information that i wouldn't want to see in ps when command is running. i typically give such flags env var name (nice!). it would be nice if go-flags allowed a way to specify a flag that cannot be specified via command line but can be filled in via env variable.

Example:

type BoshOpts struct {
	// -----> Global options
	UsernameOpt string `description:"Override username" env:"BOSH_USER"`
	PasswordOpt string `description:"Override password" env:"BOSH_PASSWORD"`
...

and still helpfully be visible in help description:

$ bosh -h|head -...

Application Options:
  -v, --version            Show CLI version
  ???                      Override username [$BOSH_USER]
  ???                      Override password [$BOSH_PASSWORD]
      --uaa-client=        Override UAA client [$BOSH_CLIENT]
...

wdyt?

[jessevdk]

This feels a bit out of scope for flags (it's really not a flag anymore now). I can see why it's useful, I'm just not sure it belongs in go-flags core. This is quite easy to implement yourself, and you can just append these kind of env vars to the help/usage output of go-flags.

[cppforlife]

it's really not a flag anymore now

given that currently flag values can come from cmd args (default) and optionally from env (may be other sources in future), it is only symmetrical that you can opt out of default source and only opt into env source.

...you can just append these kind of env vars to the help...

it just feels like going against the abstraction.

Sent from my iPhone

On Dec 18, 2016, at 3:09 AM, Jesse van den Kieboom [email protected] wrote:

This feels a bit out of scope for flags (it's really not a flag anymore now). I can see why it's useful, I'm just not sure it belongs in go-flags core. This is quite easy to implement yourself, and you can just append these kind of env vars to the help/usage output of go-flags.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[sylr]

Totally support this request.

I too have declared only env and would really like the associated vars to be filled by go-flags.

https://github.com/sylr/prometheus-azure-exporter/blob/5247eaf48a412297bfe46572bea5bbbd52efbd49/main.go#L30-L39

[awskii]

Also it's not clear that env-only variables are omitted from parsing (didn't seen that before). If that variable is required and not provided, parse error is not returned which is highly unexpected behaviour.

This is quite easy to implement yourself

as easy as implement flags from stdlib, but here we could get needed type out of the box and gather configuration in one place, avoiding lots of boilerplate code (hello viper).

@jessevdk don't you think that ini-files support is less related to the core than environment variables mapping?)