osgar.lib.config: allow overrides in dict merging#612
Conversation
| @@ -53,8 +54,14 @@ def config_load(*filenames, application=None): | |||
|
|
|||
|
|
|||
| def merge_dict(dict1, dict2): | |||
There was a problem hiding this comment.
The naming is somewhat confusing. It took me some time to realize that dict1 and dict2 and not necessarily dictionaries.
There was a problem hiding this comment.
I tried to refactor the code, maybe it is better now.
osgar/lib/config.py
Outdated
| if isinstance(dict1, t) and isinstance(dict2, t): | ||
| return dict2 | ||
|
|
||
| if not isinstance(dict1, dict) or not isinstance(dict2, dict): |
There was a problem hiding this comment.
One type that I do not see supported and we have in the config is lists. Unfortunately, I do not see a generic solution. For a list that represents, for example, image size, it is better when the second config overrides the first one. For a list of links between nodes, appending the second list to the first one would be more convenient.
Any opinions about what we should do with lists?
I have a weak preference for "override" and for figuring out what to do with links separately.
There was a problem hiding this comment.
For some length of time I have my doubts about the whole config file approach. Maybe we should not have config files but python modules/functions that build the required config and then exec into the graph. I have been on and off wrestling with configurability for example in #525 without getting anywhere. Maybe run_solution.bash should be run_solution.py so that the configuration can be built in an actual programming language?
There was a problem hiding this comment.
Yes, every configuration eventually becomes Turing complete. But let's not do that yet.
What should we do about the lists for now. Override?
There was a problem hiding this comment.
I've added the override for list and tuple.
If every configuration eventually becomes Turing complete, it is better when that is done through an actually usable language rather than some ad hoc solution (just look at CMake "language").
osgar/lib/config.py
Outdated
| if isinstance(dict1, t) and isinstance(dict2, t): | ||
| return dict2 | ||
|
|
||
| if not isinstance(dict1, dict) or not isinstance(dict2, dict): |
There was a problem hiding this comment.
Yes, every configuration eventually becomes Turing complete. But let's not do that yet.
What should we do about the lists for now. Override?
|
@m3d ? |
3 participants
@jisa Does this help?