| Description | |
|---|---|
| Project |   |
| Code quality |     |
| Docs and support |   |
OmegaConf is a hierarchical configuration system, with support for merging configurations from multiple sources (YAML config files, dataclasses/objects and CLI arguments) providing a consistent API regardless of how the configuration was created.
OmegaConf 2.0 stable version.
Install with pip install --upgrade omegaconf
Run the live tutorial :
Interpolations are never considered to be missing anymore, even if they point to a missing node
When resolving an expression containing an interpolation pointing to a
missing node, an InterpolationToMissingValueError exception is raised
When resolving an expression containing an interpolation pointing to a
node that does not exist, an InterpolationKeyError exception is raised
key in cfg returns True whenever key is an interpolation, even if it cannot be resolved (including interpolations to missing nodes)
get() and pop() no longer return the default value in case of interpolation resolution failure (same thing for OmegaConf.select())
If throw_on_resolution_failure is False, then resolving an
interpolation resulting in a resolution failure always leads to the
result being None (instead of potentially being an expression computed
from None)
Fixes #543 Fixes #561 Fixes #562 Fixes #565
Restore and deprecate the old env resolver for backward
compatibility with OmegaConf 2.0
The new oc.env resolver keeps the string representation of
environment variables, and does not use the cache
The new oc.decode resolver can be used to parse and evaluate strings
according to the OmegaConf grammar
Fixes #383 Fixes #573 Fixes #574
Notes:
This is a squashed version of #321.
env resolver now parses environment variables in a way that is consistent with the new interpolation grammarFixes #100 #230 #266 #318
It would be nice to enable recursive interpolation.
Example :
![[Feature Request] resolve individual resolver arguments](https://avatars.githubusercontent.com/u/24327668?v=4)
import omegaconf
from omegaconf import OmegaConf
OmegaConf.register_resolver("plus", lambda x,y: float(x)+float(y))
c = OmegaConf.create({
"i": 1,
'key1': '${plus:1,2}',
'key2': '${plus:${i},2}'
})
print(c.key1)
# 3.0
print(c.key2)
# '${plus:1,2}'
But one would hope to get 3.0 out
Note that 2 recursion would be enough to enable the user to create deeper interpolation if they need it (by calling an other key which had already been interpolated).
enhancementThis is to fix #100
Doc and tests are missing, I'm aware of it, I wanted to first get feedback on the implementation itself, in case there'd be any major concern.
The main parsing logic is in _evaluate_complex(), it's actually not too complex since we can sequentially iterate on all characters in the string and evaluate interpolations in the order we encounter their end }. So the core logic is simple but there are still "details" to be addressed (see concerns below).
This is not a super efficient implementation: (i) there are many string copies in the process, and (ii) the worst case complexity is quadratic in case of deep nesting (Edit: not anymore, see comment below). That being said, I don't expect it to be a real issue in the large majority of practical use cases.
A few potential concerns:
a: 1 as config, then ${${a}} used to evaluate to the string"${1}", when now it would crash when trying to resolve this new interpolation. Hopefully people were not relying on this!None value instead of crashing in case of syntax error. This isn't good, but right now the only two flags to trigger a crash are throw_on_missing and throw_on_resolution_failure, because there could be no syntax error in the previous code (for instance ${a}_${a would be resolved into "1_${a"). Should I add a throw_on_parsing_failure flag?${a resolves to "${a" while ${a}_${a triggers a parsing failure. This inconsistency isn't good => I was thinking of using my new interpolation logic whenever it's not a simple interpolation but there is still a ${ in the string to be parsed, which should address this issue. Thoughts?${ and } tokens, although it probably wouldn't be that hard. Let me know if you think this is important.The support added for relative keys in select (#656) was a breaking change. in 2.0, when select is called on a nested node, it's already relative. #656 made that select absolute, which is a breaking change.
A non breaking fix is to keep nested selects relative, but add support for relative syntax (specifically for going up the hierarchy). The resulting behavior is shown below and can be a bit surprising:
from omegaconf import OmegaConf
cfg = OmegaConf.create(
{
"a": {
"b": {
"c": 10,
}
},
"z": 10,
},
)
# works on 2.0
assert OmegaConf.select(cfg.a, "") == {"b": {"c": 10}}
assert OmegaConf.select(cfg.a, "b") == {"c": 10}
# new behavior, going up one level (as an example):
assert OmegaConf.select(cfg.a, ".") == {"a": {"b": {"c": 10}}, "z": 10}
assert OmegaConf.select(cfg.a, ".a") == {"b": {"c": 10}}
assert OmegaConf.select(cfg.a, ".z") == 10
In most scenarios, going up a level requires two dots. but since OmegaConf.select on a nested node is already relative to that node, only one dot is needed.
The API is establishing the non-breaking implementation. An alternative is to make this breaking (the behavior from #656).
The non-breaking behavior will look weird when using select inside custom resolvers using select as an alternative way to access nodes (this is using a planned oc.select resolver that will just call OmegaConf.select):
a: 10
foo:
a: 20
b: ${oc.select: .a) # relative to foo, one level up: 10
b: ${oc.select: a) # relative to foo: 20
# as opposed to:
c: ${a} # absolute: 10
c: ${.a} # relative: 20
I am not particularly happy with this. On the one hand, select being relative to the node it's called on is intuitive and is the current behavior. On the other hand, it's inconsistent with interpolations. Thoughts?
I am planning to merge this because this is fixing an unintentional breaking change, but let's decide if we actually want to make this an intentional breaking change (and at the point, users will need to use relative select syntax to get relative behavior, like in interpolations.
EDIT: Final solution is different than anything above. read the code and look at the tests to understand it.
Currently resolvers are not getting access to the config structure. It will be helpful to allow it.
Example use case:
OmegaConf.register_resolver("len", lambda root, value: len(OmegaConf.select(root, value)))
c = OmegaConf.create({
'list': [1,2,3],
'list_len': '${len:list}'
})
assert cfg.list_len == 3
The documentation of dataclasses has this example for init=False:
@dataclass
class C:
a: float
b: float
c: float = field(init=False)
def __post_init__(self):
self.c = self.a + self.b
It just means that c is not an argument to the __init__. I find this useful sometimes when I have a configuration value that can be computed from other configuration values.
Describe the solution you'd like
OmegaConf should just ignore fields that have init=False set.
Describe alternatives you've considered
One alternative is to not give a type annotation to the field and just set it to MISSING:
>>> @dataclass
... class C:
... a: float
... b: float
... c = MISSING
... def __post_init__(self):
... self.c = self.a + self.b
...
>>> d = OmegaConf.structured(C)
>>> d.a = 3
>>> d.b = 4
>>> o = OmegaConf.to_object(d)
>>> o.c
7.0
This works, but it is a bit sad that we have to accept the loss of the type annotation.
Additional context
init=False. >>> from dataclasses import dataclass, field
>>> @dataclass
... class C:
... a: float
... b: float
... c: float = field(init=False)
... def __post_init__(self):
... self.c = self.a + self.b
...
>>> c = C(a=3, b=4)
>>> c.c
7
>>> from omegaconf import OmegaConf
>>> d = OmegaConf.structured(C)
>>> d.a = 3
>>> d.b = 4
>>> OmegaConf.to_object(d)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/tmk/.conda/envs/palbolts/lib/python3.9/site-packages/omegaconf/omegaconf.py", line 574, in to_object
return OmegaConf.to_container(
File "/home/tmk/.conda/envs/palbolts/lib/python3.9/site-packages/omegaconf/omegaconf.py", line 553, in to_container
return BaseContainer._to_content(
File "/home/tmk/.conda/envs/palbolts/lib/python3.9/site-packages/omegaconf/basecontainer.py", line 249, in _to_content
return conf._to_object()
File "/home/tmk/.conda/envs/palbolts/lib/python3.9/site-packages/omegaconf/dictconfig.py", line 735, in _to_object
self._format_and_raise(
File "/home/tmk/.conda/envs/palbolts/lib/python3.9/site-packages/omegaconf/base.py", line 190, in _format_and_raise
format_and_raise(
File "/home/tmk/.conda/envs/palbolts/lib/python3.9/site-packages/omegaconf/_utils.py", line 821, in format_and_raise
_raise(ex, cause)
File "/home/tmk/.conda/envs/palbolts/lib/python3.9/site-packages/omegaconf/_utils.py", line 719, in _raise
raise ex.with_traceback(sys.exc_info()[2]) # set end OC_CAUSE=1 for full backtrace
omegaconf.errors.MissingMandatoryValue: Structured config of type `C` has missing mandatory value: c
full_key: c
object_type=C
>>> d.c = 0
>>> OmegaConf.to_object(d)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/tmk/.conda/envs/palbolts/lib/python3.9/site-packages/omegaconf/omegaconf.py", line 574, in to_object
return OmegaConf.to_container(
File "/home/tmk/.conda/envs/palbolts/lib/python3.9/site-packages/omegaconf/omegaconf.py", line 553, in to_container
return BaseContainer._to_content(
File "/home/tmk/.conda/envs/palbolts/lib/python3.9/site-packages/omegaconf/basecontainer.py", line 249, in _to_content
return conf._to_object()
File "/home/tmk/.conda/envs/palbolts/lib/python3.9/site-packages/omegaconf/dictconfig.py", line 752, in _to_object
result = object_type(**field_items)
TypeError: __init__() got an unexpected keyword argument 'c'
This enables implementing a form of select with a default value:
Side note, we should rethink support for passing the parent node automatically on demand (${.}), it will simplify this use case.
from typing import Any
from omegaconf import OmegaConf
from omegaconf.omegaconf import _EMPTY_MARKER_
yaml = """\
a: 10
no_default: ${oc.select:${.}, a}
not_using_default: ${oc.select:${.}, a, 20}
using_default: ${oc.select:${.}, not_there, 20}
"""
def oc_select(node: Any, key: str, default: Any = _EMPTY_MARKER_):
if default is _EMPTY_MARKER_:
return OmegaConf.select(node, key)
else:
return OmegaConf.select(node, key, default=default)
OmegaConf.register_new_resolver("oc.select", oc_select)
cfg = OmegaConf.create(yaml)
assert cfg.a == 10
assert cfg.no_default == 10
assert cfg.not_using_default == 10
assert cfg.using_default == 20
Notes:
I did not like the complexity of the testing in test_grammar.py. seems like a new testing framework instead of a test designed to test some logic. I created a simpler more localized test for interpolations. happy to discuss.
while it's not very big, it can be easier to review one commit at a time.
Validate and convert interpolation results to their intended type
This PR fixes several issues:
For nested resolvers (ex: ${f:${g:x}}), intermediate resolver
outputs (of g in this example) were wrapped in a ValueNode just to
be unwrapped immediately, which was wasteful. This commit pushes the
node wrapping to the very last step of the interpolation resolution.
There was no type checking to make sure that the result of an interpolation had a type consistent with the node's type (when specified). Now a check is made and the interpolation result may be converted into the desired type (see #488).
If a resolver interpolation returns a dict / list, it is now wrapped into a DictConfig / ListConfig, instead of a ValueNode. This makes it possible to generate configs from resolvers (see #540). These configs are read-only since they are being re-generated on each access.
Fixes #488 Fixes #540
Is your feature request related to a problem? Please describe.
I would like to be able to merge one config section into another, and augment the result with new keys. In vanilla YAML, this is straightforwardly accomplished via anchors and the merge key tag. The following piece of code illustrates this:
import yaml
print(yaml.safe_load("""
a: &A
x: 1
y: 2
b:
<<: *A
x: 3
z: 1
"""))
results in
{'a': {'x': 1, 'y': 2}, 'b': {'x': 1, 'y': 2, 'z': 1}}
Loading the same YAML into omegaconf results in an exception:
from omegaconf import *
conf = OmegaConf.create("""
a: &A
x: 1
y: 2
b:
<<: *A
x: 3
z: 1
""")
yaml.constructor.ConstructorError: could not determine a constructor for the tag 'tag:yaml.org,2002:merge'
Describe the solution you'd like
Well it would be nice if the vanilla YAML merge key worked. However, this whole anchor/alias business is rather clumsy. Top prize would be if this could work with the interpolation feature, like so:
a:
x: 1
y: 2
b:
<<: ${a}
x: 3
z: 1
Even better would be if this worked across a merge of configs (similar to what's discussed in https://github.com/omry/omegaconf/issues/442). I.e.
from omegaconf import *
conf1 = OmegaConf.create("""
a:
x: 1
y: 2
""")
conf2 = OmegaConf.create("""
b:
<<: ${a}
x: 3
z: 1
""")
conf3 = OmegaConf.merge(conf1, conf2)
Describe alternatives you've considered I could use lists with nested mappings in them, and merge the keys in the code. Seems ugly though. I don't see any other way around it.
Additional context Current onegaconf master, python 3.6.9.
This is a minimal PR providing the possibibility to pass the same flags to OmegaConf.load() that can be used when calling OmegaConf.create().
I created a custom resolver that allows setting tuples as config values.
It worked perfectly when testing it like this OmegaConf.create("tup: ${as_tuple:1,2,3}").
However, it failed when loading the config file
tup: ${as_tuple:1,2,3}
since I am calling OmegaConf.resolve() after OmegaConf.load() (for a good reason that is out of scope here).
The error was
omegaconf.errors.UnsupportedValueType: Value 'tuple' is not a supported primitive type
I could resolve that error by altering the allow_objects flag
config._set_flag("allow_objects", True)
Despite the disclaimers in the comments about the flags API, I think it would be nice to be able to directly set them when creating a config from a file the same way we can do it when creating it programmatically.
What do you think? Did I miss anything?
Please see the code. The change is straightforward.
Since Python 3.3, the standard library provides types.SimpleNamespace which is a container similar to dicts, but can be accessed by dot notation.
I would like to have OmegaConf.to_container() / OmegaConf.to_object() emit instances of SimpleNamespace instead of dict.
Currently, users can convert OmegaConf objects into python lists and containers for named keys:
These can be dataclasses / attr classes (in the case of structured configs) or else dicts.
This provides speedups of 3 orders of magnitude when accessing an item compared to OmegaConf objects.
In my code, I want to access the config by dot notation, e.g. config.database.port.
While this works great for dataclasses / attr classes, it requires a structured config meaning the presence of all keys must be known in advance. All extra keys not present in the structured config are converted to dict which must be accessed by subscription: config["database"]["port"]
My concrete use case: In my app, users can provide custom implementations of some functions. These functions may read custom options from a hydra config. Both the parameter names and nesting levels of these options are completely user-controlled, so there is no way I can use a structured config in advance.
![[Feature Request] Use SimpleNamespace for to_container() and to_object()](https://avatars.githubusercontent.com/u/15750438?v=4)
OmegaConf.to_container(cfg, structured_config_mode=omegaconf.SCMode.SIMPLE_NS)
If the idea is well received, OmegaConf.to_object() could also convert to SimpleNamespace by default, but this is a breaking change and not a priority for me.
Describe the bug DictConfig keys do not support the same type coercion as other typed fields. For example, floats and strings are not coerced to ints for DictConfig keys, while other fields have no issue. For some reason, enum coercion seems to be the only thing that works correctly for DictConfig keys. Additionally, ListConfig type and DictConfig value type coercion seems to work just fine.
To Reproduce
import omegaconf
from omegaconf import MISSING, OmegaConf
import dataclasses
from enum import Enum
class Color(Enum):
red = "RED"
blue = "BLUE"
@dataclasses.dataclass
class Example:
a: float = MISSING # Coerces correctly
b: dict[Color, Color] = MISSING # Coerces correctly
c: dict[float, Color] = MISSING # Coerces INCORRECTLY
d: dict[Color, float] = MISSING # Coerces correctly
e: list[float] = MISSING # Coerces correctly
struct = OmegaConf.structured(Example)
cfg = OmegaConf.create(
{
"a":3,
"b":{"red":"blue"},
"c":{3: "blue"},
"d": {"red":4} ,
"e":[3,4]
}
)
merged = OmegaConf.merge(struct, cfg)
print(merged)
Expected behavior
I would expect the above code to print
{'a': 3.0, 'b': {<Color.red: 'RED'>: <Color.blue: 'BLUE'>}, 'c': {3.0: <Color.blue: 'BLUE'>}, 'd': {<Color.red: 'RED'>: 4.0}, 'e': [3.0, 4.0]}
And I do get this output if I change "c":{3: "blue"} to "c":{3.0: "blue"}
Instead I get:
omegaconf.errors.KeyValidationError: Key 3 (int) is incompatible with (float)
full_key: c.3
reference_type=Dict[float, Color]
object_type=dict
I would expect DictConfig keys to be coerced in the same way as DictConfig values, or other fields in general.
Additional context
Describe the bug
The OmegaConf.update method throws an AssertionError when the key argument passed to OmegaConf.update points inside of a DictConfig instance whose _content is None.
To Reproduce
from dataclasses import dataclass
from typing import Optional
from omegaconf import OmegaConf
from pytest import raises
@dataclass
class Child:
x: int = 123
y: int = 456
@dataclass
class Parent:
child: Optional[Child] = None
cfg = OmegaConf.structured(Parent)
with raises(AssertionError, match="Unexpected type for root: NoneType"):
OmegaConf.update(cfg=cfg, key="child.x", value=789)
Expected behavior I think OmegaConf should fail gracefully (or maybe not fail at all) in this situation rather than throwing an AssertionError.
Additional context
Edit:
$ OC_CAUSE=1 python repro2.py
Traceback (most recent call last):
File "/home/homestar/dev/mrepo/pysc/repro2.py", line 17, in <module>
OmegaConf.update(cfg=cfg, key="child.x", value=789)
File "/home/homestar/miniconda3/envs/pysc/lib/python3.10/site-packages/omegaconf/omegaconf.py", line 709, in update
assert isinstance(
AssertionError: Unexpected type for root: NoneType
I would like to be able to put equal signs and other symbols in the args list of a custom resolver. For example:
script: ${run:main.py, epochs=1000, lr=1e-5}
Currently I can work around it by wrapping each argument in quotes, but it seems strange that symbols like $%*@?| are allowed, but !#^&()=[]<>; are not.
Is your feature request related to a problem? Please describe. In situations where you have several related dicts with the same keys, it would be nice to be able to define those only once somewhere an interpolate them into all the dictionary keys, to avoid errors and repetition. It would also allow one to override the corresponding keys in all the dicts at once.
Describe the solution you'd like Being able to to something like:
model:
x_label: image
y_label: class
id_column: index
network:
_target_: my_pkg.my_network.Network
data:
${model.id_column}:
_target_: my_pkg.load_col_from_dataframe # some custom function
_partial_: true
col: ${model.id_column}
${model.y_label}:
_target_: my_pkg.load_col_from_dataframe
_partial_: true
col: ${model.y_label}
${model.x_label}:
_target_: my_pkg.load_image_from_dataframe
_partial_: true
path_col: ${model.x_label}
(This is a simplified version of what I do in serotiny
Describe alternatives you've considered No really good alternatives other than manually making sure the values match.
Additional context I would use this feature heavily in the context of a project I'm working on: https://github.com/allencell/serotiny
enhancement interpolation has-workaroundmetadata["omegaconf_ignore"] is True. (#984)Path to str was disallowed. (#934)typing.Sequence) are used in structured configs. (#991)tuple as equivalent to typing.Tuple, and likewise for dict/Dict and list/List. (#973)Path to str was disallowed. (#934)oc.dict.values resolver failed when passed a relative dotpath (#942)OmegaConf 2.2 is a major release. The most significant area of improvement in
2.2 is support for more flexible type hints in structured configs. In addition,
OmegaConf now natively supports two new primitive types, bytes and pathlib.Path.
typing.Union) (#144)typing.Optional) (#460)bytes-typed values (#844)pathlib.Path-typed values (#97)ListConfig now implements slice assignment (#736)ListConfig to a list via the ListConfig.__radd__ dunder method (#849)OmegaConf.missing_keys(), a method that returns the missing keys in a config object (#720)OmegaConf.clear_resolver(), a method to remove interpolation resolvers by name (#769)| in unquoted strings in OmegaConf interpolations (#799)OmegaConf.to_object now works properly with structured configs that have init=False fields (#789)OmegaConf.is_none(cfg, "key"). Please use cfg.key is None instead. (#547)${env} interpolations. ${oc.env} should be used instead. (#573)OmegaConf.get_resolver(). Please use OmegaConf.has_resolver() instead. (#608)OmegaConf.is_optional(). (#698)MutableMapping API, the DictConfig.items method now returns an object of type ItemsView, and DictConfig.keys will now always return a KeysView (#848)OmegaConf 2.1 is a major release introducing substantial new features, and introducing some incompatible changes. The biggest area of improvement in 2.1 is interpolations and resolvers. In addition - OmegaConf containers are now much more compatible with their plain Python container counterparts (dict and list).
@dataclass or @attr.s class. (#472)OmegaConf.has_resolver() allows checking whether a resolver has already been registered. (#608)OmegaConf.MISSING (#390)structured_config_mode keyword argument. Setting structured_config_mode=SCMode.DICT_CONFIG causes to_container to not convert Structured Config objects to python dicts (it leaves them as DictConfig objects). (#548)OmegaConf.{update, select} and in interpolations, bracketed keys may be used as an alternative form to dot notation,
e.g. foo.1 is equivalent to foo[1], [foo].1 and [foo][1]. (#179)${namespace.my_func:123}) (#539)oc.select, enabling node selection with a default value to use if the node cannot be selected (#541)oc.decode that can be used to automatically convert a string to bool, int, float, dict, list, etc. (#574)oc.dict.keys and oc.dict.values provide a list view of the keys or values of a DictConfig node. (#643)oc.create can be used to dynamically generate config nodes (#645)oc.deprecated, that enables deprecating config nodes (#681)$ is now allowed in interpolated key names, e.g. ${$var} (#600)ListConfig.append() now copies input config nodes (#601)__delitem__ can now be called with a string naming the enum member to be deleted. (#554)OmegaConf.select() of a missing (???) node from a ListConfig with throw_on_missing set to True now raises the intended exception. (#563)DictConfig.{get(),pop()} now return None when the accessed key evaluates to None, instead of the specified default value (for consistency with regular Python dictionaries). (#583)ListConfig.get() now return None when the accessed key evaluates to None, instead of the specified default value (for consistency with DictConfig). (#583)parent when creating a config from a YAML string. (#648)__getattr__ access, e.g. cfg.foo, is now raising a AttributeError if the key "foo" does not exist (#515)__getitem__ access, e.g. cfg["foo"], is now raising a KeyError if the key "foo" does not exist (#515)cfg.get("foo"), now returns None if the key "foo" does not exist (#527)Omegaconf.select(cfg, key, default, throw_on_missing) now requires keyword arguments for everything after key (#228)???) instead of auto-expanding (#411)register_resolver() is deprecated in favor of register_new_resolver(), allowing resolvers to (i) take non-string arguments like int, float, dict, interpolations, etc. and (ii) control the cache behavior (now disabled by default) (#426)OmegaConf.select(), DictConfig.{get(),pop()}, ListConfig.{get(),pop()} no longer return the specified default value when the accessed key is an interpolation that cannot be resolved: instead, an exception is raised. (#543)InterpolationResolutionError or a subclass of it. (#561)key in cfg now returns True when key is an interpolation even if the interpolation target is a missing ("???") value. (#562)OmegaConf.select() as well as container methods get() and pop() do not return their default value anymore when the accessed key is an interpolation that cannot be resolved: instead, an exception is raised. (#565)${foo:a,}) are deprecated in favor of explicit quoted strings (e.g., ${foo:a,""}) (#572)env resolver is deprecated in favor of oc.env, which keeps the string representation of environment variables, does not cache the resulting value, and handles "null" as default value. (#573)OmegaConf.get_resolver() is deprecated: use the new OmegaConf.has_resolver() to check for the existence of a resolver. (#608)typing.Dict is now deprecated. (#663)OmegaConf 2.1 is a major release introducing substantial new features, and introducing some incompatible changes. The biggest area of improvement in 2.1 is interpolations and resolvers. In addition - OmegaConf containers are now much more compatible with their plain Python container counterparts (dict and list).
@dataclass or @attr.s class. (#472)OmegaConf.has_resolver() allows checking whether a resolver has already been registered. (#608)OmegaConf.MISSING (#390)structured_config_mode keyword argument. Setting structured_config_mode=SCMode.DICT_CONFIG causes to_container to not convert Structured Config objects to python dicts (it leaves them as DictConfig objects). (#548)OmegaConf.{update, select} and in interpolations, bracketed keys may be used as an alternative form to dot notation,
e.g. foo.1 is equivalent to foo[1], [foo].1 and [foo][1]. (#179)${namespace.my_func:123}) (#539)oc.select, enabling node selection with a default value to use if the node cannot be selected (#541)oc.decode that can be used to automatically convert a string to bool, int, float, dict, list, etc. (#574)oc.dict.keys and oc.dict.values provide a list view of the keys or values of a DictConfig node. (#643)oc.create can be used to dynamically generate config nodes (#645)oc.deprecated, that enables deprecating config nodes (#681)$ is now allowed in interpolated key names, e.g. ${$var} (#600)__delitem__ can now be called with a string naming the enum member to be deleted. (#554)OmegaConf.select() of a missing (???) node from a ListConfig with throw_on_missing set to True now raises the intended exception. (#563)DictConfig.{get(),pop()} now return None when the accessed key evaluates to None, instead of the specified default value (for consistency with regular Python dictionaries). (#583)ListConfig.get() now return None when the accessed key evaluates to None, instead of the specified default value (for consistency with DictConfig). (#583)parent when creating a config from a YAML string. (#648)__getattr__ access, e.g. cfg.foo, is now raising a AttributeError if the key "foo" does not exist (#515)__getitem__ access, e.g. cfg["foo"], is now raising a KeyError if the key "foo" does not exist (#515)cfg.get("foo"), now returns None if the key "foo" does not exist (#527)Omegaconf.select(cfg, key, default, throw_on_missing) now requires keyword arguments for everything after key (#228)???) instead of auto-expanding (#411)register_resolver() is deprecated in favor of register_new_resolver(), allowing resolvers to (i) take non-string arguments like int, float, dict, interpolations, etc. and (ii) control the cache behavior (now disabled by default) (#426)OmegaConf.select(), DictConfig.{get(),pop()}, ListConfig.{get(),pop()} no longer return the specified default value when the accessed key is an interpolation that cannot be resolved: instead, an exception is raised. (#543)InterpolationResolutionError or a subclass of it. (#561)key in cfg now returns True when key is an interpolation even if the interpolation target is a missing ("???") value. (#562)OmegaConf.select() as well as container methods get() and pop() do not return their default value anymore when the accessed key is an interpolation that cannot be resolved: instead, an exception is raised. (#565)${foo:a,}) are deprecated in favor of explicit quoted strings (e.g., ${foo:a,""}) (#572)env resolver is deprecated in favor of oc.env, which keeps the string representation of environment variables, does not cache the resulting value, and handles "null" as default value. (#573)OmegaConf.get_resolver() is deprecated: use the new OmegaConf.has_resolver() to check for the existence of a resolver. (#608)typing.Dict is now deprecated. (#663)ListConfig.__contains__ optimized, about 15x faster in a benchmark (#529)Minor release deprecating an uncommonly used feature.
${foo.bar} if foo is a value node (instead of silently returning ${foo}) (#364)This is mostly a bugfix release. The notable change is the config.pretty() is now deprecated in favor of OmegaConf.to_yaml().
OmegaConf 2.0 is a major release introducing substantial new features, and introducing some incompatible changes. The biggest new feature is Structured Configs, which extends OmegaConf into an schema validation system as well as a configuration system. With Structured Configs you can create OmegaConf objects from standard dataclasses or attr classes (or objects). OmegaConf will retain the type information from the source object/class and validate that config mutations are legal.
This is the biggest OmegaConf release ever, the number of unit tests more than trippled (485 to 1571).
Simple dataclasses configuration management for Python with hocon/json/yaml/properties/env-vars/dict support, based on awesome and lightweight pyhocon parsing library.
Python Decouple: Strict separation of settings from code Decouple helps you to organize your settings so that you can change parameters without having
SimpadLib v1.0.6 What is this? This is a python library programmed by Ashe Muller that allows users to interface directly with their SimPad devices, a
EXE4J Configuration Extractor This script helps reverse engineering Portable Executable files created with EXE4J by extracting their configuration dat
MOHAconfig Gerador de arquivo de configuraĆ§Ć£o para Medal of Honor: Airborne MOHA - Gerador de arquivo de configuraĆ§Ć£o. Essa aplicaĆ§Ć£o foi feita em pyt
A modern simfile parsing & editing library for Python 3
pari-utils A Python library to parse PARI/GP configuration and header files. This is mainly used in the code generation of https://github.com/sagemath
ConfZ ā Pydantic Config Management ConfZ is a configuration management library for Python based on pydantic. It easily allows you to load your configu
Config files for my GitHub profile.
environs: simplified environment variable parsing environs is a Python library for parsing environment variables. It allows you to store configuration
Sync your configuration to remote, such as vimrc. You can use EscSync to manage your configure of editor, shell, etc.
phyaml A simple YAML validator for Programming Historian lessons. USAGE: python3 ph-lesson-yaml-validator.py lesson.md The script automatically detect
A tool to manage configuration files, build scripts etc. across multiple projects.
In the name of God, the Most Gracious, the Most Merciful. PF-PY-YMLEnv Documentation Install and update using pip: pip install -U PF-PY-YMLEnv Please
NAPALM vs NETCONF/OPENCONFIG Abstracts Multi vendor network management and autom
python-dotenv Python-dotenv reads key-value pairs from a .env file and can set them as environment variables. It helps in the development of applicati
Python Left-Right Parser Pyleri is an easy-to-use parser created for SiriDB. We first used lrparsing and wrote jsleri for auto-completion and suggesti
Python Decouple: Strict separation of settings from code Decouple helps you to organize your settings so that you can change parameters without having
Organize Django settings into multiple files and directories. Easily override and modify settings. Use wildcards in settings file paths and mark setti
Inject your config variables into methods, so they are as close to usage as possible
62 Dec 23, 2022
2.3k Dec 30, 2022
2 Jan 08, 2022
6 Jun 29, 2022
1 Dec 31, 2021
38 Nov 01, 2022
3 Sep 18, 2022
164 Dec 27, 2022
7 May 17, 2022
920 Jan 04, 2023
0 Nov 21, 2022
1 Nov 07, 2021
8 Dec 14, 2022
2 Jan 20, 2022
1 Jan 17, 2022
5.5k Jan 04, 2023
106 Dec 06, 2022
6.6k Jan 04, 2023
942 Jan 05, 2023
7 Dec 14, 2022