Add viper.IsNonDefaultSet to check if a value is set by config, not default value

[haoming29]

Preflight Checklist

• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Problem Description

Currently, viper.IsSet returns true if the key has a default value. However, it would be useful to know if a value is set by the user via config/env/etc.

Proposed Solution

Have a new method to check if a key is set by config/env other than the default value. It seems that viper keeps the default values of keys in v.defaults map:

viper/viper.go

Line 1400 in d539b7a

val = v.searchMap(v.defaults, path)

so it's doable to implement this feature.

Alternatives Considered

No response

Additional Information

No response

[github-actions]

👋 Thanks for reporting!

A maintainer will take a look at your issue shortly. 👀

In the meantime: We are working on Viper v2 and we would love to hear your thoughts about what you like or don't like about Viper, so we can improve or fix those issues.

⏰ If you have a couple minutes, please take some time and share your thoughts: https://forms.gle/R6faU74qPRPAzchZ9

📣 If you've already given us your feedback, you can still help by spreading the news,
either by sharing the above link or telling people about this on Twitter:

https://twitter.com/sagikazarmark/status/1306904078967074816

Thank you! ❤️

[sagikazarmark]

@haoming29 can you give an example where this is useful?

Viper is moving away from this direction, so even if we add it now, it may have to be removed later, so I'd like to understand the use case for such a feature.

Thanks!

[jhiemstrawisc]

The software stack @haoming29 use viper in would benefit from knowing this for a few reasons:

• Configuration can be performed via CLI flags, environment variables, and config files, and these can be layered (ie some config files take precedence over others). On startup, we'd like to display to the user the complete configuration, split into the values they provide and the values that are inherited from default. I'd even argue it would be nice to tell the user how each configuration option is set up in this case (eg from a file, from an env var, etc)
• In some cases, our defaults are constructed to make the program work across a range of backends, even if those settings are not optimal for any of the backends. We'd like to use those defaults, but warn users who might explicitly configure the same defaults that they can eek out more performance.
• We have a broad set of configuration options, and many of them don't make sense to set up if another option is already toggled. We get around conflicting configurations because the presence of some mean that others are never checked. We'd still like to have defaults set for all of them, but warn the user explicitly if they start configuring things that don't make sense to configure together.