-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nested keys don't work with AutomaticEnv #160
Comments
I believe this works in my confer fork - dots are substituted with underscores. It's a behavior I realized I needed to clarify during testing. I don't particularly encourage the usage of my fork because I've drifted away from go-land, BUT it would be good to confirm your use case. It might rekindle my interest in reconciling my changes! I struggled to merge |
We just ran into this today. Between this issue and #71 , it's getting pretty hard to work with nested keys. |
I've put together a simple change for viper that simply converts "." characters into "_" characters when retrieving an environment variable. What do people think about that as a solution to this issue? Are there edge cases that I'm missing? I included a test case to validate the behavior of setting an environment A_B and then calling Get("a.b") |
I'm just familiarizing with viper as I want to replace my own env/config utility. I found out that In config file I have something like I can retrieve it using If env prefix is set using Furthermore I can use github.com/spf13/pflag library and define a flag like this: Again It's sad that documentation is non existent and one has to dig into code to find little gems like this. |
@awdrius Interesting. Have you tried incorporating your approach with calls to AutomaticEnv() or Unmarshal() ? The issues seem to crop up in there, when Viper should map environment variables to nested structures but fails to do so. Your first example works because configuration files are parsed correctly, in terms of nested keys. The second example, where you parse STS_CASSANDRA_HOSTS from the environment, is interesting. I would guess that it's parsing STS_CASSANDRA_HOSTS into CASSANDRA_HOSTS (a single string), replacing the underscore with a dot and then that is being found when you call GetStringSlice() but it's being found as a single string, not as a nested struct. Not sure how to prove that off-hand, I'm going off of some other experiments that I've done. I have no idea on the third example, I have not tried working with command-line flags yet. |
@four2five Actually these were all a single example. And yes, AutomaticEnv() is part of it but I have not tried it with Unmarshal(). Here is a cleaned version of my test (settings.go):
Configuration file is like this:
These are test run results:
|
I too am being bitten by this issue, please see a failing test below:
For now, I am working around this problem by doing a second pass over the returned values from
|
Fixes #71, #93, #158, #168, #209, #141, #160, #162, #190 * Fixed: indentation in comment * Fixed: Get() returns nil when nested element not found * Fixed: insensitiviseMaps() made recursive so that nested keys are lowercased * Fixed: order of expected<=>actual in assert.Equal() statements * Fixed: find() looks into "overrides" first * Fixed: TestBindPFlags() to use a new Viper instance * Fixed: removed extra aliases from display in Debug() * Added: test for checking precedence of dot-containing keys. * Fixed: Set() and SetDefault() insert nested values * Added: tests for overriding nested values * Changed: AllKeys() includes all keys / AllSettings() includes overridden nested values * Added: test for shadowed nested key * Fixed: properties parsing generates nested maps * Fixed: Get() and IsSet() work correctly on nested values * Changed: modifier README.md to reflect changes
Fixed by #195 |
This works only for environment variables? I mean, the .env files seems to have the same problem. EXAMPLE_A_B=3 Lines 1423 to 1430 in 72b022e
The same principle shouldn't be applied here? I'm new using viper, so am I missing something here? Thanks |
I came across this issue just now. For me, the root cause was |
Periods are not appropriate for environment variables, so for a nested key
a.b
with an environment prefixexample
, you might run your program like this:But this example code:
Will print:
This is inconsistent, as nested keys in viper are accessed with a
.
separator, not an underscore.Tangential relation to #71.
The text was updated successfully, but these errors were encountered: