How to ignore values frequently changed in a file managed by chezmoi?

[nagromc]

I'm using Scoop to manage apps on Windows, and its config file (%USERPROFILE%\.config\scoop\config.json) looks like this:

{
    "last_update":  "2024-01-17T21:50:23.5241939+01:00",
    "scoop_branch":  "master",
    "scoop_repo":  "https://github.com/ScoopInstaller/Scoop",
    "aria2-enabled":  true
}

The problem is whenever I run scoop update, the last_update value will be updated to the current timestamp, and chezmoi apply will detect a conflict.

Is there a way to ignore these changes?

[bradenhilton]

A modify template is the solution. Here is my scoop config:

modify_config.json:

// chezmoi:modify-template
// chezmoi:template:line-endings=crlf
// chezmoi:template:left-delimiter=//{{
//{{- $currentConfig := .chezmoi.stdin | fromJson -}}
//{{- $modifiedConfig := .chezmoi.stdin | fromJson -}}

//{{- $_ := set $modifiedConfig "use_external_7zip" true -}}

//{{- if deepEqual $currentConfig $modifiedConfig -}}
//{{-   .chezmoi.stdin }}
//{{- else -}}
//{{-   $modifiedConfig | toPrettyJson }}
//{{- end -}}

In your case, you can replace use_external_7zip with aria2-enabled. You may get a diff after this, but you shouldn't get any more after that.

[nagromc]

Wow. The solution is not really intuitive, but it works! Thank you.

My feeling is that this solution works only for JSON files. What if I had an XML, or TOML file? Would it be a good idea to just ignore a change for a particular text (typically, an attribute like in the question) on the line? Is that even possible to implement that without too much hassle?

I’ll ping @twpayne

[bradenhilton]

A perfectly intuitive solution to this problem doesn't exist, because it's caused by incorrect behavior, and that behavior has subtle differences for basically every software it appears in.

If you were to instruct chezmoi to ignore the line (or range of lines), it would break the moment the lines were rearranged for whatever reason. I opened an issue with Scoop to prevent it from invariably rewriting its config file (which re-ordered its values) and last time I checked a while ago the fix was not live.

If you were to provide some kind of pattern, it would break the moment that pattern stopped working for whatever reason.

How should duplicate lines be handled? Should they be handled differently for different config files?

Any similar solution would also break, because they all rely on the software upholding its incorrect behavior.

This particular issue exists because scoop combines its state (last_update) with its configuration. There are many other software that do similar things, such as storing their window size and position in their config file. This is incorrect behavior. It combines values which are likely to change frequently with values which are not likely to change frequently.

My solution works around this by just outputting the existing config file if the existing JSON is the same as the modified JSON, which eliminates diffs.

Scoop's config options can be set within PowerShell, you could consider using a run_* script which executes something like if (-not (scoop config aria2-enabled)) { scoop config aria2-enabled $true } if you'd prefer.

I'm open to any ideas you might have to make this more intuitive.

[twpayne]

For TOML you can use the equivalent to fromToml and toToml template functions.

XML is broken by design. Do you have a specific .xml file that you want to modify?

For .ini files you can use https://github.com/VorpalBlade/chezmoi_modify_manager.

[nagromc]

That was exactly my problem with KeePassXC before the team changed it (keepassxreboot/keepassxc#4665): the state of the GUI was mixed up with the configuration.

I understand that handling this use case is challenging, and cannot be addressed easily for all the reasons you gave. Better ask for app maintainers to separate the state and the configuration.

Thanks for the amazing and quick support.

[halostatue]

There is a different way to do that, I think. See #2824 (reply in thread) by @bradenhilton. there is more discussion here: #2864