priority inheritance for merging

[errhammr]

I've had the idea of using nickel to manipulate existing configuration files for various other programs that are written in one of the supported formats for nickel export.

The approach I was thinking of involves the use of the import feature.

{
    defaults
        | not_exported
        | default
        = import "default.yaml",
    specific
        | not_exported
        = import "config_server_a.yaml",
    merged = defaults & specific
}

Unfortunately, the default priority is not inherited to all the children of defaults so a merge will cause issues.

Example:

{
    defaults
        | not_exported
        | default
        = {
            test1 = "from defaults",
            test2 | default = "from defaults",
            test3 | priority -1 = "from defaults",
            test4 | priority 1 = "from defaults",
        },
    config
        | not_exported
        = {
            test1 = "from config",
            test2 = "from config",
            test3 = "from config",
            test4 = "from config",
        },
    merged = defaults & config
}

Evaluating the above (using nickel version nickel-lang-cli nickel 1.10.0 (rev cargore) installed using cargo) errors out with a merge conflict:

$ nickel eval priorityInheritance.ncl
error: non mergeable terms
   ┌─ /storage/emulated/0/Syncthing/All Devices/dev/nickel/priorityInheritance.ncl:6:21
   │
 6 │             test1 = "from defaults",
   │                     ^^^^^^^^^^^^^^^ cannot merge this expression
   ·
14 │             test1 = "from config",
   │                     ^^^^^^^^^^^^^ with this expression
   ·
19 │     merged = defaults & config
   │              ----------------- originally merged here
   │
   = Merge operands have the same merge priority but they can't be combined.
   = Both values are of type String but they aren't equal.
   = String values can only be merged if they are equal

[exit 1]

I understand why this error occurs. And I understand that there's a difference between having the priority of the field only applied to the field itself vs. having it recursively applied to all its descendants. Therefore, it would probably be unwise to change the behavior of the current priority syntax. Instead, a new syntax construct might be better suited for explicitly stating the wish to apply a given priority recursively to all children of a field that do not have their own priority metadata.

To adapt the first example from above to illustrate what I mean (notice the addition of the fictional metadata keyword recursive_priority):

{
    defaults
        | not_exported
        | recursive_priority default
        = import "default.yaml",
    specific
        | not_exported
        = import "config_server_a.yaml",
    merged = defaults & specific
}

Is this form of priority inheritance a use case that future versions of nickel might want to support? My rust skills are insufficient to implement this myself but I figured it might be a useful addition to the language.

Or is there a way to manipulate the priority recursively by use of a function or a feature of the standard library? That might work, too, if priorities can be changed programmatically.

[yannham]

Your request does make sense; in fact it was implemented some time ago (see e.g. #279), with the keyword rec default and rec force. However, this was pre-1.0. When implementing RFC005, the semantics and the way of implementing recursive priority was not as trivial as before. At the time being, we disabled them with the intent of revisiting the issue later. Since there was no demand in between, this has been stalling, to be honest.

So, to answer your initial question, we do want to support this again in future versions. It just needs a bit more thinking around the implementation. The first step would be to open a proper issue to track this again.