FB Hydra extending configurations

Question

I'm trying to use Facebook's Hydra package to configure a project. In the example below, I've tried to keep names as generic as possible. Suppose that there are multiple model architecture types (e.g. different types of segmentation task) that the user can load. The main application loads the appropriate model using a task key in the model config.

My config file tree looks like:

├── config.yaml
├── data
│   └── default.yaml
├── model
│   ├── task_1
│   │   ├── base.yaml
│   │   ├── variant_1.yaml
│   │   ├── variant_2.yaml
│   └── task_2
│       ├── base.yaml
│       ├── default.yaml
│       ├── variant_1.yaml

My default config contains:

defaults:
  - data: default
  - model: task_1/base

Loading this works, and I get a model key with the contents of the base.yaml config file.

Now, suppose base has a key called config that maps to a dictionary of hyperparameters. I would like to load an extended config e.g. variant_1.yaml which extends that config and of keeps the original parameters in the base configuration.

launch("config", overrides=["model=task_1/variant_1"])`

In variant_1.yaml I've tried:

defaults:
  - base

but this gives an exception:

MissingConfigException: In 'model/task_1/variant_1': Could not load 'model/base'.

if I use task_1/base instead, then this works, but then the entire base config is loaded as a separate dictionary key called task_1:

{
  task_1: {from base},
  config: {... from variant_1}}
}

rather than:

{
...
config: { base, extended with other params from variant_1}
}

What is the correct way to inherit with this sort of nested directory structure (or is there a more canonical way to do this)? The documentation from Hydra seems to suggest this is straightforward, but I can't figure it out from the examples.

Answer 1

First off, I strongly recommend that your config group will be model/task_1, e.g:

- model/task_1: base

What you are trying to do is not really tested and I can see some weirdness that is caused by it.

The the page for extending configs. It describes how to achieve proper config extension.

This would probably do what you want:

defaults:
  - base@_here_