Provisional options

[tailhook]

Background

The usual way to handle configuration is to error on every unknown option. This is important so that typos don't have any catastrophic effects.

Still, we have _underscored options which serve two purposes:

1. Allow putting something that is &aliased and used via *anchors later
2. Provide additional metadata to external tools (i.e. we have vagga-box- specific options, that are put in vagga.yaml)

Motivation

Vagga's use case: we put vagga.yaml in git-versioned repository. And many users pull that repository and run vagga. What is important for this use case is that all users have a single vagga.yaml, and they may have a different versions of vagga command installed. In particular, somebody may have vagga from the master branch.

So a user might want to configure a new feature of vagga without requiring everyone to upgrade.

Design

When adding an option, like myoption add another option, which looks like _future-myoption. For example, if we would introduce isolate-network in this way we would have:

command:
  test: !Supervise
    _future-isolate-network: true
    children: # ...

This way vagga test would run in isolated network in newer vagga. In older version of vagga tests will still work.

Open Questions

1. Should we allow _future-myoption options without supporting myoption. The idea behind this, is that actual myoption may mean different thing when stabilized, and we may support different behavior through prefixed and unprefixed thing.

2. Should we allow any option specified with the prefix?

3. How to cleanup _future- prefixed options? (the initial idea is to remove the prefix on next stable release)

4. Alternatives to _future prefix? (any shorter ones?)

Alternatives

1. Use some kind of overrides, inheritance or nesting for a configuration file. While for some use cases it's fine, it makes learning pretty simple tool very hard.

2. Configure all in provisional options in user settings (there is a settings config in user's home which is usually not committed into the repository)

3. Use different granularity for options. I.e. define new command instead of adjusting one. Validate command-specific options only when the command is run. (also maybe allow defining new commands in settings).

/cc @anti-social, @popravich