Since Hugo is such a heavy user of Viper, this patch adds an
after_success section to the Travis-CI build that validates the Viper
commit by attempting to build Hugo and executing `hugo -s docs`.
This patch handles issue #222.
It breaks Hugo, will have to test/investigate.
Erro when building Hugo docs:
```
ERROR: 2016/08/05 11:19:23 site.go:1208: unable to process menus in site config
ERROR: 2016/08/05 11:19:23 site.go:1209: Unable to Cast map[string]interface {}{"pre":"<i class='fa fa-space-shuttle'></i>", "weight":-20, "url":"/commands/", "name":"Hugo Cmd Reference", "identifier":"commands"} of type map[string]interface {} to []interface{}
```
This reverts commit 7402856f06.
I stumbled over this when trying to merge multiple configs.
```
viper.SetConfigName("default")
err := viper.MergeInConfig()
```
which caches file path resolvemenet in `v.configFile`
and then
```
viper.SetConfigName("prod")
err := viper.MergeInConfig()
```
which reuses `v.configFile` without updating it accordingly to the new name.
See c1ccc378a0/viper.go (L1240)
This patch updates the package used for parsing TOML content from
"github.com/BurntSushi/toml" to "github.com/pelletier/go-toml" as the
latter uses a more accepted OSS license (MIT), enabling the inclusion of
Viper or projects that depend on Viper in projects that have licensing
requirements incongruent with the license of the previous TOML package.
This patch replaces the PR https://github.com/spf13/viper/pull/208 after
discussing the matter with @spf13 and deciding to update the TOML parser
instead of making TOML build-optional.
Then checking the file name in the event handler. This seems to be the only robust way
of handling changes from a single file on multiple platforms and editors.
See #142
* Only add *the* config file, not all possible folders
* Trigger reload on both write and create events;
the latter is what we get from atomic save editors (like TextMate) once https://github.com/go-fsnotify/fsnotify/pull/111 is merged
See #142
This patch fixes a bug with how Viper handle's key casing when keys are
nested. While Viper is generally case-insensitive, this was not the case
with regards to nested keys. This patch makes nested keys insensitive as
well.
This patch adds the `MergeConfig` and `MergeInConfig` functions to
enable reading new configuration files via a merge strategy rather
than replace. For example, take the following as the base YAML for a
configuration:
hello:
pop: 37890
world:
- us
- uk
- fr
- de
Now imagine we want to read the following, new configuration data:
hello:
pop: 45000
universe:
- mw
- ad
fu: bar
Using the standard `ReadConfig` function the value returned by the
nested key `hello.world` would no longer be present after the second
configuration is read. This is because the `ReadConfig` function and
its relatives replace nested structures entirely.
The new `MergeConfig` function would produce the following config
after the second YAML snippet was merged with the first:
hello:
pop: 45000
world:
- us
- uk
- fr
- de
universe:
- mw
- ad
fu: bar
Examples showing how this works can be found in the two unit tests
named `TestMergeConfig` and `TestMergeConfigNoMerge`.
Using an interface allows people to use their favourite flag system
with viper without being restricted to the semantics of pflag or the
standard library.
This change introduce two new functions `BindFlagValues` and
`BindFlagValue` that behave like `BindFlags` and `BindFlag` but using
the new interface as values.
This change also introduces two internal structures to transform
`*pflag.FlagSet` and `*pflag.Flag` into the new interface. This way,
viper keeps working as expected for people that are currently using the
pflag package without breaking backwards compatibility.
Signed-off-by: David Calavera <david.calavera@gmail.com>
This patch refactors the IsSet function to examine the keys in order
to see if a key is set instead of simply checking if a value is nil.
This change is necessary due to the fact that default values via
flag bindings will result in the old logic always being true for
the IsSet function due to a type's default value such as 0 for an
integer or an empty string for a string. While a type's default
value may be preferable when getting the value for a key, it
results in a false positive when determining if a key is actually
set. This change enables users to detect whether a key is set by
only returning a flag's value if it has changed.
This patch alters the way flags are handled to coincide with the
documentation on the Viper README. The documentation indicated that flag
bindings were late, when in fact they were very, very early. This patch
changes flag bindings to behave as late bindings.
Schley Andrew Kutz