Configs currently have no control over how they are cached. They just generate layers, which are cached by BYOC internally. This was meant to make it easier to write config classes, but it also makes it hard to write configs that interact with other configs. In particular, I recently added an UpstreamConfig class to SWMB that basically gives one object access to configs from another. This is useful for dealing with hierarchies.
The problem is that, because of the way that configs are cached, upstream configs need to be loaded after the config they want to mimic is accessible and loaded. Getting this right turns out to be pretty finicky, and the error messages are kinda confusing because you need to understand that different objects may have different views of the same config. Conceptually, it should only matter that the config in question is accessible at the time when it is needed for something.
In order to solve these problems, I need to give the Config class control over how it is cached. Specifically, what I have in mind is:
Configs will have a version number, which parameters will use to determine if they need to be recalculated.
There may also be a special version number indicating that there will never be another update, which would be necessary for @cached_property-style caching to be used.
Configs currently have no control over how they are cached. They just generate layers, which are cached by BYOC internally. This was meant to make it easier to write config classes, but it also makes it hard to write configs that interact with other configs. In particular, I recently added an
UpstreamConfigclass to SWMB that basically gives one object access to configs from another. This is useful for dealing with hierarchies.The problem is that, because of the way that configs are cached, upstream configs need to be loaded after the config they want to mimic is accessible and loaded. Getting this right turns out to be pretty finicky, and the error messages are kinda confusing because you need to understand that different objects may have different views of the same config. Conceptually, it should only matter that the config in question is accessible at the time when it is needed for something.
In order to solve these problems, I need to give the Config class control over how it is cached. Specifically, what I have in mind is:
@cached_property-style caching to be used.