-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to refactor the code, maybe it is better now.
osgar/lib/config.py
Outdated
for t in simple_types: | ||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
for t in simple_types: | ||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ? |
@jisa Does this help?