Closed sanderpick closed 3 years ago
Thanks for the clarification. That is confusing for sure. I'm surprised viper doesn't have an option to go camelCase to UPPER_SNAKE_CASE.
If camelcase mapped to _
, you could create an indeterminate situation with a config like the following:
apiSecret: <secret>
api
secret: <secret>
Both of those entries would map to the env var HUB_API_SECRET
, whereas now the first one gets mapped to HUB_APISECRET
.
There is a Viper property called EnvKeyReplacer
that could be useful here. Need to think about it more.
Yep, we're using it: https://github.com/textileio/textile/blob/master/cmd/config.go#L81
The thing is, you can't map camelcase since Viper removes uppercases. We could move to underscores in the config or nested values:
api: ...
api_key: ...
api_secret: ...
or
api:
multi_addr: ...
key: ...
secret: ...
Fixes
apiSecret
key lookup from the viper config.There are three ways to leverage config values:
Viper lowercases config keys when binding to env vars, e.g., the var for api secret is
HUB_APISECRET
, notHUB_API_SECRET
.This is confusing because in other program configs we are mapping flags to nested config value. Here's an example from
hubd
:That will map to an env var of
HUB_ADDR_API
due to the use of.
inKey
. We could update thehub
CLI to use nested config values, or just provide better document for the env vars. Personally, I like the use of a single level (not nested) config file forhub
, but open to opinions.