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?
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:
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.