The configured key is in uppercase and is converted to lowercase

[wpecker]

The configured key is in uppercase and is converted to lowercase
E.g:

[greenSDK]
   roleArn = "aaaa"
   accessKey = "xxxx"
   accessSecret = "yyyy"

If you pass the following test is normal,

roleArn = viper.GetString ("greenSDK.roleArn")
accessKey = viper.GetString ("greenSDK.accessKey")
accessSecret = viper.GetString ("greenSDK.accessSecret")

If the following way to directly access the map, found in the map key all converted to lowercase
BCfg = viper.GetStringMapString ("greenSDK")

the value is :

map[string]string{"accesssecret":"yyyy", "rolearn":"aaaa", "accesskey":"xxxx"}

[gbbr]

Nobody cares 😭

[jose-sanchezm]

I just discovered this behaviour and I find it very annoying and somewhat weird. Part of my yaml configuration file is a map of key-values that I want to check against:

---
testing:
  enabled: true
  variables:
    myVar1: val1
    myVar2: val2

I expect to get the values of the yaml sub-tree testing.variables as a map and it seems that I can do it with viper.GetStringMapString("testing.variables") however, since it sets them to lowercase I receive an unexpected set of variables. I would say that GetStringMapString should retain the same keys as it finds because if not the configuration file that I'm reading with viper is not at all the configuration file I have in disk.

[sagikazarmark]

Viper is case-insensitive by default, because this is the way it can match flags, env vars and file keys.

Consider the following: you want TESTING_VARIABLES_MYVAR1 to override the matching key in your config file. But which one do you map it to if you have the following in your file:

testing:
  variables:
    myVar1: val1
    myvar1: val1
    mYvar1: val2

Ultimately config is supposed to be accessed directly by viper.Get commands, or mapped to structs, but I understand that there are cases when case-sensitivity is required.

I've recently hit the same wall as well. I can't really promise anything on this front, except that I will work on it and try to find a solution. PRs and help is always welcome, although in this case I hardly think a PR would be accepted as is 🙂

[sagikazarmark]

Duplicate of #1014