Position of callback option in struct declaration is significant

[raghur]

Based on various posts here on using the callback option to load settings from INI file, it isn't immediately clear that where you declare the option in the struct is relevant.

If you declare the callback option first, then it gets called before the other items are parsed/and or defaults set - which basically leads to problems. So always place callback option declarations last in your struct definition.

For ex - this test below fails. to make it pass, move the Config declaration to the end.

func TestIniRequiredSlice_ShouldNotNeedToBeSpecifiedOnCli(t *testing.T) {
	type options struct {
		Config func(string) `short:"c" default:"xyz" no-ini:"true"`
		Items  []string     `long:"item" required:"true"`
		Other  string       `short:"o"`
	}
	var opts options
	ini := `
[Application Options]
item=abc`
	args := []string{"-o", "other"}

	parser := NewParser(&opts, Default)
	opts.Config = func(string) {
		inip := NewIniParser(parser)
		inip.ParseAsDefaults = true
		t.Logf("Before ini: %v", opts)
		inip.Parse(strings.NewReader(ini))
		t.Logf("After ini: %v", opts)
	}

	_, err := parser.ParseArgs(args)
	if err != nil {
		t.Errorf("Unexpected failure: %v", err)
	}
	if opts.Items[0] != "abc" {
		t.Errorf("Expected first option to be abc, but was %v", opts.Items[0])
	}

}

[jessevdk]

I agree this is confusing. I'm willing to make ini parsing have priority so that later defaults don't override from ini (and vice versa that ini defaults override builtin defaults). This is a bit of a breaking change, but I don't see how someone would rely on that exact behavior so I think it should be ok.

[jessevdk]

Should be fixed in next release.