user-supplied variable names -- vote for inclusion in v1

[speter]

Vote for this tentative pull request (PR) to be merged into branch v1 either by using 👍 or by adding a comment describing your use case (and ideally link to source). Other (constructive) feedback is also welcome.

Currently (in the v1 branch) all variable names are supplied by the developer (who implements the configuration struct) as field names (or in field tags). In some situations it is useful to allow the user (who edits the configuration file) to define arbitrary variable names. An example of such usage is the [alias] section in .gitconfig.

This PR adds support for user-supplied variables. A section can contain either all developer-supplied or all user-supplied variables. With user-supplied variables the variable names are case-insensitive (so it is not as simple as a map[string]Something), and the order of variables is not preserved. This is to maintain consistency with developer-supplied variables.

A section with user-defined variables is declared as a struct with two members: an embedded gcfg.Idxer and a map[gcfg.Idx]*Something, for example:

var cfg = &struct {
    Alias struct {
        gcfg.Idxer
        Vals map[gcfg.Idx]*string
    }
}{}

After using gcfg.Read*Into, looking up a variable is done as follows:

val := cfg.Alias.Vals[cfg.Alias.Idx("lg")]

Iterating through the variables is done as follows (the case and order of names is undefined):

for _, name := range cfg.Alias.Names() {
    val := cfg.Alias.Vals[cfg.Alias.Idx(name)]
    ...
}

[xorpaul]

👍
I'm using it for my monitoring agent, that has user defined commands for monitoring checks.

source: https://github.com/xorpaul/gorpe/blob/master/gorped.go#L253
Example config: https://github.com/xorpaul/gorpe/blob/master/gorpe.gcfg
Everything under the commands section is non-static.

[speter]

Thanks for the feedback. For the record, yours seems to be the only use in public code on Github: https://github.com/search?q=gcfg.Idxer&type=Code . I think there should be at the very least 3-5 use cases so that we can decide whether the feature is suitable for the wide public.

On a side note, I'd suggest not to use Idxer for the [main] section (just use a plain struct and refer to the struct fields rather than map values). And the gcfg format doesn't support underscores in variable names; in case it happens to work with Idxer, that's a bug that I need to fix. (The intent for disallowing variable names with underscores is to keep the format uniform with hyphens only, so that there are no surprising inconsistencies in case a save/write/dump feature is added in the future.)

[peterebden]

As I mentioned in #10 , we've been using a more basic approach with similar goals; among other things, we want to support an [alias] section analogous to git's. The gcfg reading code is here: https://github.com/thought-machine/please/blob/master/src/core/config.go, although I don't think we have a config file using that feature checked in anywhere public yet.

I'm definitely +1 for the feature, I'm not sure I like the requirement of this implementation to embed gcfg-specific objects into my struct though; I find it nice that the struct doesn't normally have to have any special features for gcfg to parse into it, similar to encoding/json etc.

[speter]

@peterebden Thanks for the feedback again. Note that git alias is also case-insensitive. I know that having to embed gcfg.Indexer is a bit clumsy but (so far) it's the best compromise I've managed to find that allows case-insensitive matching.

[traetox]

Throwing my vote in on getting this merged into v1. We are currently using this branch in our config library so that we can have both structured and dynamic elements in our configs.

Here is our wrapped config library that "does the things": https://godoc.org/github.com/gravwell/ingest/config#VariableConfig
The branch allowed us to have full backwards compatibility while enabling a really dynamic config system where we could define and reflect structs back into arbitrary types.

So, big up-vote from us, would be really nice to see this merged into the mainline branch. Also, thank you for the library, its great!.