Is organizing config files within a config group in a directory structure a supported feature in hydra?

779 Views Asked by At

Let's assume a config group foo and config files organized in the following directory structure:

conf
├── foo
│   ├── bar
│   │   ├── a.yaml
│   │   ├── b.yaml
│   │   ├── c.yaml
│   └── baz
│       ├── d.yaml
│       ├── e.yaml
│       └── f.yaml

Each of the yaml files sets the package to foo using # @package foo. When running the corresponding application, I can simply override foo by specifying something like foo=bar/a or foo=baz/f. Thereby, the sub-directories bar and baz indicate a certain category withing a larger set of possible configurations.

While this works fine for standard use in hydra, some more advanced features of hydra appear to be not compatible with this structure. For instance, I would like to use glob in conjunction with the directory structure like this foo=glob(bar/*) to sweep over all configs of a certain category. However, this does not appear to work as glob does not find any configs in this example. Also if I assign an invalid config to foo and hydra lists the available options, the list is empty.

This makes me wonder if structuring within a config group is a generally supported feature in hydra, and just some corner cases are not covered yet, or if I am using hydra wrong and directories should not be used for organizing configs in a group?

1

There are 1 best solutions below

2
Omry Yadan On

This is not recommended, but not explicitly prohibited. There are scenarios where this can help, but as you have discovered it does not play well with some other features. A config group contains other config groups/configs.

Hydra 1.1 is adding support for recursive default lists which will make this kind of scenario more common. See The Defaults List documentation page:

├── server
│   ├── db
│   │   ├── mysql.yaml
│   │   └── sqlite.yaml
│   └── apache.yaml
└── config.yaml

In the scenario from the example there, the entities under server/db are different than the entities under server, so such globing would not make sense.