How inheritance handles nested configs

[DirkKuhn]

Hi,

I noticed that when using inheritance, nested configs are not recursively merged but simply overriden by the child.
Here is an example

base = make_config(a=dict(b=0, c=0))
cfg = make_config(a=dict(c=1, d=1), bases=(base,))

base is of the form

a:
  b: 0
  c: 0

I would expect cfg to be of the form

a:
  b: 0
  c: 1
  d: 1

but it is

a:
  c: 1
  d: 1

Can this be changed?

I am unfamiliar with the return type of make_config, but if they were of type dict or DictConfig the following might work:

from collections.abc import MutableMapping, Iterable


def index_with_keys(cfg: MutableMapping, keys: Iterable[str]) -> MutableMapping:
    list_of_tuples = [(k, cfg[k]) for k in keys]
    return dict(list_of_tuples)


def merge_mappings(cfg: MutableMapping, base: MutableMapping) -> MutableMapping:
    if len(cfg) == 0 or len(base) == 0:
        return {**cfg, **base}

    cfg_keys = set(cfg.keys())
    base_keys = set(base.keys())

    only_cfg_keys = cfg_keys - base_keys
    only_base_keys = base_keys - cfg_keys
    intersection_keys = cfg_keys & base_keys

    merged_intersection = {k: merge(cfg[k], base[k]) for k in intersection_keys}

    return {
        **index_with_keys(cfg, only_cfg_keys),
        **index_with_keys(base, only_base_keys),
        **merged_intersection
    }


def merge(cfg: MutableMapping, base: MutableMapping) -> MutableMapping:
    cfg_primitive = {k: v for k, v in cfg.items() if not isinstance(v, MutableMapping)}
    base_primitive = {k: v for k, v in base.items() if not isinstance(v, MutableMapping)}
    merged_primitives = {**base_primitive, **cfg_primitive}

    cfg_mappings = {k: v for k, v in cfg.items() if isinstance(v, MutableMapping)}
    base_mappings = {k: v for k, v in base.items() if isinstance(v, MutableMapping)}
    merged_mappings = merge_mappings(cfg_mappings, base_mappings)

    return {**merged_primitives, **merged_mappings}


if __name__ == '__main__':
    base = dict(a=dict(b=0, c=0), b=0, c=0)
    cfg = dict(a=dict(c=1, d=1), c=1, d=1)

    print(cfg)
    print(base)
    print(merge(cfg, base))

It prints

{'a': {'c': 1, 'd': 1}, 'c': 1, 'd': 1}
{'a': {'b': 0, 'c': 0}, 'b': 0, 'c': 0}
{'b': 0, 'c': 1, 'd': 1, 'a': {'b': 0, 'c': 1, 'd': 1}}

though the order changes.

What do you guys think?

[DirkKuhn]

I also noticed that the defaults list simply gets replaced the the child, i.e.

base = make_config(hydra_defaults=[{'a': 'a0'}, {'b': 'b0'}, '_self_'])
cfg = make_config(hydra_defaults=[{'b': 'b1'}, {'c': 'c1'}, '_self_'], bases=(base,))

results in cfg being of the form

defaults:
- b: b1
- c: c1
- _self_

I think this makes sense, as cfg can be in a different group/package.

[rsokl]

All of hydra-zen's config-creation functions - builds, make_config - return dynamically-generated dataclass types, so the inheritance behavior you are seeing is just straightforward class inheritance.

You can get the behavior you are looking for by using OmegaConf.merge:

from hydra_zen import make_config
from omegaconf import OmegaConf

base = make_config(a=dict(b=0, c=0))
cfg = make_config(a=dict(c=1, d=1), bases=(base,))

OmegaConf.merge(base, cfg)

produces

{'a': {'b': 0, 'c': 1, 'd': 1}}

[DirkKuhn]

Thanks, OmegaConf.merge works nicely.

[alexanderswerdlow]

I wanted to follow-up on this answer because I spent a long-time trying to do something similar, trying many complicated variants, until I realized the answer is simple. Please correct me if I'm wrong but from my testing, if you are storing the configs from make_config and want a config to inherit from a stored one, you simply need to set hydra_defaults in the make_config args to the desired parent name (if it's in the same group, with no prefix).

E.g.,

store(make_config(a=dict(b=0, c=0)), name='first', package="_global_", group='experiments')
store(make_config(a=dict(b=1)), name='second', package="_global_", group='experiments', hydra_defaults=["first"])

I suppose you could then retrieve the config by doing something like store[group][(group, parent)] but that would be different from the config object itself.

Hope this helps someone looking for something similar in the future!