You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You want to load this JSON within an existing config. This could be achieved with:
importjsonfromomegaconfimportDictConfig, OmegaConf# Define a custom resolver to load JSON files.defload_json(path):
withopen(path) asf:
returnjson.load(f)
OmegaConf.register_new_resolver("load_json", load_json)
# Combine it with `oc.create` to generate a DictConfig with the content of this file.cfg=OmegaConf.create({"model": "${oc.create:${load_json:'model.json'}}"})
assertisinstance(cfg.model, DictConfig)
assertcfg.model.n_units_per_layer[1] ==1000
If oc.create wasn't used, then cfg.model would be a plain dictionary that wouldn't support all DictConfig features (like accessing a field with the syntax cfg.model.n_units_per_layer)
Alternatives
It is possible for custom resolvers to explicitly call OmegaConf.create(..., parent=_parent_) to always generate config nodes. The objective of introducing oc.create is (i) to make this more straightforward and (ii) to add more flexibility, so that config nodes are only generated when explicitly requested (there are situations where keeping plain dicts / lists may be preferred).
Additional context
In current master (d93905e) when a resolver outputs a dict/list, it is automatically converted into a DictConfig / ListConfig. However this may not always be a good thing and will be reverted when introducing oc.create (see discussion: Introduce new oc.env and oc.decode resolvers #606 (comment))
The text was updated successfully, but these errors were encountered:
Motivation
A new resolver
oc.create
would make it easier to dynamically generate config objects from lists and dictionaries.For instance imagine you have the following JSON file
model.json
with the following content:You want to load this JSON within an existing config. This could be achieved with:
If
oc.create
wasn't used, thencfg.model
would be a plain dictionary that wouldn't support all DictConfig features (like accessing a field with the syntaxcfg.model.n_units_per_layer
)Alternatives
It is possible for custom resolvers to explicitly call
OmegaConf.create(..., parent=_parent_)
to always generate config nodes. The objective of introducingoc.create
is (i) to make this more straightforward and (ii) to add more flexibility, so that config nodes are only generated when explicitly requested (there are situations where keeping plain dicts / lists may be preferred).Additional context
oc.create
(see discussion: Introduce newoc.env
andoc.decode
resolvers #606 (comment))The text was updated successfully, but these errors were encountered: