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:
Allow putting something that is &aliased and used via *anchors later
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:
This way vagga test would run in isolated network in newer vagga. In older version of vagga tests will still work.
Open Questions
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.
Should we allow any option specified with the prefix?
How to cleanup _future- prefixed options? (the initial idea is to remove the prefix on next stable release)
Alternatives to _future prefix? (any shorter ones?)
Alternatives
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.
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)
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).
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
_underscoredoptions which serve two purposes:&aliasedand used via*anchorslatervagga-box- specific options, that are put invagga.yaml)Motivation
Vagga's use case: we put
vagga.yamlin 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 singlevagga.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
myoptionadd another option, which looks like_future-myoption. For example, if we would introduce isolate-network in this way we would have:This way
vagga testwould run in isolated network in newer vagga. In older version of vagga tests will still work.Open Questions
Should we allow
_future-myoptionoptions without supportingmyoption. The idea behind this, is that actualmyoptionmay mean different thing when stabilized, and we may support different behavior through prefixed and unprefixed thing.Should we allow any option specified with the prefix?
How to cleanup
_future-prefixed options? (the initial idea is to remove the prefix on next stable release)Alternatives to
_futureprefix? (any shorter ones?)Alternatives
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.
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)
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