Feature: Ability to define partial configurations

[Doc-Steve]

Hi there,

When using all the existing dot-file managers, I’m curious if Nix could offer a unique feature that would make it significantly superior to traditional dot-management: defining partial configurations. Currently, the only option is to either set all configurations for a program in the Nix code or leave them completely unmanaged. There‘s no middle ground.

Let me elaborate on this:

I often find myself wanting to define only a subset of the possible configuration settings for a program within my NixOS infrastructure code. I want to leave other settings untouched or allow users to modify them. It would be incredibly helpful if I could define settings for a JSON, YAML, or INI configuration file, and NixOS would automatically insert or replace these settings in the existing dot files.

I’m wondering if such a feature is even feasible and if this is something that could be done with hjem?

[eclairevoyant]

I think this is similar to #113, is my understanding correct?

[Doc-Steve]

It’s something different.

#113 is meant for complete files, I think similar to a “mutable” option like this.

My feature request extends beyond this. Imagine a definition like this:

        xdg.config.files.”config.json” = {
          generator = lib.generators.toJSON { };
          value = {
            templates = “/templatesdir”;
          };
          # add or reset only defined values, leave everything else untouched
          partial = true;
        };

This would simply add or modify the value templates of an existing config.json file.

{
  “background”: “green”,
  “warnings”: true
}

->

{
  “background”: “green”,
  “warnings”: true,
  “templates”: "/templatesdir"
}

The user can still use the app GUI to change other settings, but every NixOS switch will only revert the value of templates to its defined state.

I hope I described it in an understandable way.

[HigherOrderLogic]

Maybe ignore_modification in smfh will solve this.

[eclairevoyant]

No, it will not; it would only solve #113.

[eclairevoyant]

This is essentially asking hjem to parse the existing (modified) config file before activation, merge it with the declarative configuration, and then deploy the merged file again. That seems out of scope for hjem. At most what might be in scope for hjem would be to provide the machinery to allow passing a function to parse existing config files, or a command that transforms to a language readable by nix (e.g. JSON).

[Doc-Steve]

Sounds interesting. How would the „flow“ applying these self defined merger functions (if I understood right) then be like?

[eclairevoyant]

Currently we have e.g.

        xdg.config.files."test/bar.json" = {
          generator = lib.generators.toJSON { };
          value = {
            foo = 1;
            bar = "Hello world!";
            baz = false;
          };
        };

I envision a new option alongside generator - let's call it parser - that will read the file. We already have fromJSON and fromTOML as builtins, but this would support other cases.

Then I think we would also have to support some kind of new type like "merge".

The main concern I see with something like this is the level of impurity needed to achieve it...

The other possibility would be to define an option that lets you run arbitrary commands to read the file and handle the merging - but if that command fails, then activation fails. I'm not so confident about that approach either atm. @NotAShelf if you have any thoughts?

[Doc-Steve]

So the imaginary new format would be something like this?

        xdg.config.files."test/bar.json" = {
          generator = lib.generators.toJSON { };
          parser = lib.parsers.fromJSON { };
          value = {
            foo = 1;
            bar = "Hello world!";
            baz = false;
          };
        };

That means if "parser != null" then the "bar.json" would be read/parsed first and then merged with "value" before "generator" would be executed.

You are right about the impurity of "bar.json", only the "value" parts would be "pure". It reminds me of the homemanger "mkOutofStoreSymlink" workarounds for impurity.

I totally agree that this is some kind of a philosophical question, what means "purity" in this context - and making a decision on project level will lead to discussions.

How about letting the user decide if/how he deals with the purity question himself. A "solution" achieving this could be something like this:

        xdg.config.files."test/bar.json" = {
          generator = lib.generators.toJSON { };
          writeHook = "script merging files $GENERATED & $DESTINATION and write the new file to $DESTINATION";
          value = {
            foo = 1;
            bar = "Hello world!";
            baz = false;
          };
        };

The hook could be similar to backupCommand in homeManager.

The "writeHook" function will be responsible for creating the "$DESTINATION" file. The user will decide how this is done, considering all the potential implications.

This script is called after the generator creates the file from "values" but instead of replacing the previous file in the destination directory.

I appreciate the open discussion. I believe I'm not the only one who would find many use cases for such a "partial" dot-file feature.

[eclairevoyant]

This is not a space to advertise projects with (undisclosed, even) AI usage, thanks. (We also won't entertain moderation discussions on this point, so let's keep replies on-topic regarding any possible fixes here.)