-
Notifications
You must be signed in to change notification settings - Fork 1
Composable settings #86
Copy link
Copy link
Open
Labels
product: placeosIssue relates to PlaceOS ProductIssue relates to PlaceOS Productstatus: requires planningFeature Request Pending SRSFeature Request Pending SRStype: discussionIssue that can be resolved with discussionIssue that can be resolved with discussiontype: enhancementnew feature or requestnew feature or request
Description
Metadata
Metadata
Assignees
Labels
product: placeosIssue relates to PlaceOS ProductIssue relates to PlaceOS Productstatus: requires planningFeature Request Pending SRSFeature Request Pending SRStype: discussionIssue that can be resolved with discussionIssue that can be resolved with discussiontype: enhancementnew feature or requestnew feature or request
It would be nice to extend the current approach to settings layering ('closest' overrides) to allow driver authors to define alternate behaviour when duplicate keys exist. This enable configurations that use deep object merges, list concatenation, min/max and other binary operations across layers to form the final output.
A good reference for this is the NixOS module types: https://nixos.org/manual/nixos/stable/index.html#sec-option-types-custom.
Previous approach: acaprojects/ruby-engine#16.
The implementation above allowed merge behaviour to be specified on access. Implementation here may be better suited to declaring this as part of a setting definition. This will ensure that any external systems providing a merged view (e.g. PlaceOS/backoffice#165) also apply the same behaviour as well as providing the ability to cache outputs following first access.