Embedded structs don't have their config merged up

[abraithwaite]

When processing command line flags, you must specify the embedded structs name or tag when loading configuration. This is unlike the behavior of other deserializers (json, primarily).

An example is much easier to understand than this is to explain:

abraithwaite at alan-mbpr in ~GOPATH/src/github.com/segmentio
15:58:58 $ go run play.go -name "blah" -D.location "SF"
Hello, blah
{"name": "asdf", "location": "NY"}
{"location":"SF","name":"blah"}
abraithwaite at alan-mbpr in ~GOPATH/src/github.com/segmentio
15:59:14 $ go run play.go -name "blah" -location "SF"
Usage:
  play [-h] [-help] [options...]

Options:
  -D object

  -D.location string

  -config-file source
        Location to load the configuration file from.

  -name string
        (default blah)

Error:
  flag provided but not defined: -location

exit status 1

For the file: https://gist.github.com/abraithwaite/3f74d9fbd06dbcba0c2ac14d61cc2a09#file-play-go

It would be preferable (although it would be a breaking change, maybe that can be avoided) for the properties on D to be merged up to C without needing a prefix. Perhaps we can get away with a special tag like, but not equal to -.

[achille-roussel]

Would you be able to submit a patch?

Although there may be code that rely on the current behavior that would get broken by such a change.

Is your current workaround to copy the fields directly in the struct?

[abraithwaite]

My current workaround is just to live with a prefix. It's not a major issue right now and I don't plan on working on it anytime soon, but it's low hanging fruit for anyone who wants to take a shot.

[achille-roussel]

Cool.

I've been thinking about how to avoid those kinds of discrepancies. Currently we build an intermediary representation of the configuration in memory, which we then convert to the configuration struct type.

Instead of doing this we could serialize the configuration to JSON, then use the standard JSON decoder to load values into the configuration struct. This way there can be no behavior differences (this is the approach taken by packages like https://github.com/ghodss/yaml for example).

Food for thoughts!

[stevevls]

In order to avoid breaking compatibility, what do you guys think about using _ as the special tag to indicate that the embedded struct shouldn't be prefixed?

I'm thinking about taking a stab at this too (my particular use case is creating and embedding general Suppressor configuration to be shared between the Kafka and NSQ apps). Happy to brainstorm further because this would be a really cool feature.

[achille-roussel]

That sounds like a good idea to me 👍

[achille-roussel]

Doing it backward-compatible seems like a good first step, if you want to make it the default then we can tag a v1 release of the package, and introduce the change afterward.

[abraithwaite]

This was fixed in #23.