Return metadata about structures

[sagikazarmark]

First of all, thanks for this great package! It's really useful in many scenarios, one of which is unmarshaling configuration in Viper.

We are dealing with a problem in Viper for quite some time now (or should I say can't really deal with it). Namely, under certain conditions, Viper cannot map environment variables to config keys and as a result, they don't show up in unmarshaled structs. This last part is done by mapstructure, the rest is not, so at it's core this isn't a mapstructure issue, but mapstructure might be able to provide a solution.

Viper provides a way to automatically discover environment variables matching a config key. The problem is: Viper doesn't know what key that is, unless you specifically tell it some way (eg. set a default value). In these cases, Viper cannot unmarshal data on a struct, because it doesn't know where to unmarshal it.

One possible solution we are looking at is detecting keys automatically from a struct itself, using mapstructure. Calling Decode with a struct input and a map[string]interface{} output. That should give us the keys in the struct that Viper could use to automatically find environment variables.

You can read more about the issue itself here: spf13/viper#761

Sadly, there are a couple problems with this approach as well:

• as pointed in the above issue multiple times, omitempty would cause empty values not being returned in the map
• the above solution is probably not very efficient

So to the point I'm trying to make in this issue (sorry about the long description): do you think it would make sense and would you accept PRs for a function that instead of decoding a struct into a map, would instead return information about the struct, more precisely the set of keys this struct would be turned into, ignoring omitempty. That's the information that Viper needs anyway, but I guess we can find a broader use case and implement a more generic solution that provides as much information about the struct as possible.

Not sure if I explained well-enough what I propose. I'm not even sure this should be done by mapstructure, but it would be convenient since we use mapstructure for the decoding part, so we have to stick to its mechanisms which means we would have to duplicate a bunch of stuff if we were to solve this internally in Viper.

Thanks!

[mitchellh]

I don't FULLY understand (but haven't spent a lot of time reading all the materials you linked to). However, on the surface, this sounds like it fits fine if you add it to the Metadata struct that mapstructure optionally already supports. If that could provide some info for you then perhaps this could work?

[sagikazarmark]

To put it differently: there are situations when config keys are not known to Viper, only when they are looked up, but when unmarshaling onto a struct (using mapstructure) Viper doesn't know what to lookup, so it just throws everything at mapstructure that it knows about.

If maptstructure can expose some information about the structure (field names), then Viper would know what to look up.

So yeah, I think the proposed solution could work.