We have seen how to use Structured Configs as configuration, but they can also be used as a schema (i.e. validating configuration files). To achieve this, we will follow the common pattern of Extending Configs - but instead of extending another config file, we will extend a Structured Config.
This page shows how to validate the config files
against a Structured Config schema.
Given the config directory structure:
We will add Structured Config schema for each of the config files above and store in the
Config Store as
Then, we will use the Defaults List in each config to specify its base config as follows:
One difference in the source code is that we have removed the Defaults List from the
The primary Defaults List will come from
my_app.py (Click to expand)
When Hydra composes the final config object it will use the config schemas as specified in the Default Lists.
Like before, Hydra will catch user errors in the command line:
Use --info commands to see how a config was composed (Expand)
In the above example, the schema we used was stored in the same config group. This is not always the case, for example - A library might provide schemas in its own config group.
Here is a modified version of the example above, where a mock database_lib is providing the schemas we want to validate against.
The Defaults List entry for the base config is slightly different:
- We refer to the config with an absolute path because it is outside the subtree of the db config group.
- we override the package to
_here_to ensure that the package of the schema is the same as the package of the config it's validating.