Preflight Checklist

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

Problem Description

Currently many of the Viper fields are package-private and inaccessible to the application code. This means that it's hard to get the configuration of Viper itself.

For example, when Viper cannot find the configuration file, I want to show the list of searched directories to the user. This is stored in v.configPaths, which is package-private. Of course I know that once I do v.AddConfigPath(".") it turns "." into an absolute path and stores it, and so I could do that as well when showing the paths to the user. That feels like unnecessary bookkeeping just to work around the struct field being package-private.

Another example are the name and locations fields in ConfigFileNotFoundError. If I want to present the error in a different way than produced by ConfigFileNotFoundError.Error(), I can't.

Proposed Solution

Make fields more public, especially when their access doesn't matter much. In the above case, there is no harm in making the ConfigFileNotFoundError fields public, as Viper doesn't start behaving differently when somebody modifies them. For the Viper struct itself I can imagine that this is more sensitive; in this case getter functions that return a copy of the field's value (so the original cannot be modified through a reference) would be good to have.

Alternatives Considered

No response

Additional Information

My application is something that people install & run on their own machines. It's not meant for technical folks, and thus having control over what is shown and what wording is used is quite important.

Comment From: ldez

This issue is similar to #288.

I think instead of exposing the field, it would be possible to add 2 methods: - Viper.ConfigPaths(): returns a clone of the configPaths fields - Viper.SetConfigPaths([]string) or Viper.SetConfigPaths(...string): resets the current paths and sets a new slice of paths.

This is useful when you have two kinds of configuration sources: - .foo.xxx with a set of configuration paths (ex: ./) - foo.xxx with another set of configuration paths (ex: ./config/)

A PR was opened on the topic but closed and not merged: #280

Comment From: drsybren

That would work too. I don't care much about the exact way this is resolved, but I do care about the informatino my application can obtain from Viper. I'm trying to make the app as user-friendly as possible, and that means guiding them to the right place to put config files.

Comment From: github-actions[bot]

Issues with no activity for 30 days are marked stale and subject to being closed.