You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is not a bug in a strict sense; chezmoi is not behaving the way I expect it to, and I hope to make the case here that my expectations agree with how it should work.
I would like to:
keep an exact_ directory in my source dir
conditionally ensure the absence of that directory on certain systems via .chezmoiremove
chezmoi diff shows that it would add the directory to my target dir, but I would expect .chezmoiremove to take precedence over a file attribute, since the former offers more expressive and fine-grained control than the latter.
It appears that adding the file to .chezmoiignore as well resolves this problem—but leaves us having to duplicate entries between the two files. So perhaps another way of stating this "bug" report is that, IMO, entries in .chezmoiremove should be implicitly ignored, as well.
Of course, there are more complex cases where the correct behavior is not so clear. What if we list a file in .chezmoiremove that is within an exact_ directory?
# .chezmoiremove
foo/bar
but
chezmoi
└── exact_foo
├── bar
└── baz
IMO, the behavior of .chezmoiremove here should mirror that of .chezmoiignore—which currently ignores the listed file and generates a non-exact copy of the directory foo.
$ chezmoi doctorRESULT CHECK MESSAGEok version v2.49.0, commit 2e0573779db0c42717585ac8abc4ad1ab814dfb2, built at 2024-06-10T20:04:26Z, built by goreleaserok latest-version v2.49.0ok os-arch linux/amd64 (Debian GNU/Linux 12 (bookworm))ok uname Linux gossamer 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linuxok go-version go1.22.4 (gc)ok executable /usr/bin/chezmoiok upgrade-method sudo-upgrade-packageok config-file ~/.config/chezmoi/chezmoi.toml, last modified 2024-06-18T09:46:03-07:00warning source-dir ~/.local/share/chezmoi is a git working tree (dirty)ok suspicious-entries no suspicious entrieswarning working-tree ~/.local/share/chezmoi is a git working tree (dirty)ok dest-dir ~ is a directoryok umask 022ok cd-command found /bin/bashok cd-args /bin/bashinfo diff-command not setok edit-command found /usr/bin/nvimok edit-args /usr/bin/nvimok git-command found /usr/bin/git, version 2.39.2ok merge-command found /usr/bin/vimdiffok shell-command found /bin/bashok shell-args /bin/bashinfo age-command age not found in $PATHok gpg-command found /usr/bin/gpg, version 2.2.40info pinentry-command not setinfo 1password-command op not found in $PATHinfo bitwarden-command bw not found in $PATHinfo bitwarden-secrets-command bws not found in $PATHinfo dashlane-command dcli not found in $PATHinfo doppler-command doppler not found in $PATHinfo gopass-command gopass not found in $PATHinfo keepassxc-command keepassxc-cli not found in $PATHinfo keepassxc-db not setinfo keeper-command keeper not found in $PATHinfo lastpass-command lpass not found in $PATHok pass-command found /usr/bin/pass, version 1.7.4info passhole-command ph not found in $PATHinfo rbw-command rbw not found in $PATHinfo vault-command vault not found in $PATHinfo vlt-command vlt not found in $PATHinfo secret-command not set
Additional context
N/A
The text was updated successfully, but these errors were encountered:
Thanks for spotting this. This is an interesting case of non-orthogonality in chezmoi.
The tl;dr is that .chezmoiremove is a separate system to chezmoi's source state and they don't interact well. Use the remove_ attribute on the directory instead.
Note that this is not specific to exact_ directories, so I'll ignore exact_.
In a sense, the configuration that you have is inconsistent: it states that foo and foo/bar should exist (because they are present in the source state) and also that foo should be removes. The reason that chezmoi does not detect the inconsistency is because chezmoi's order of operations is roughly:
Read the source state.
Make a list of files and directories that match any .chezmoiremove lines.
Apply the source state.
Remove the files and directories found in stage 2.
In your case, foo does not exist at stage 2, so it is not added to the list, and therefore created in stage 3 and not removed in stage 4.
Instead, use the remove_ attribute on foo, which will tell chezmoi to remove the directory if it is empty.
Describe the bug
This is not a bug in a strict sense; chezmoi is not behaving the way I expect it to, and I hope to make the case here that my expectations agree with how it should work.
I would like to:
exact_
directory in my source dir.chezmoiremove
chezmoi diff
shows that it would add the directory to my target dir, but I would expect.chezmoiremove
to take precedence over a file attribute, since the former offers more expressive and fine-grained control than the latter.It appears that adding the file to
.chezmoiignore
as well resolves this problem—but leaves us having to duplicate entries between the two files. So perhaps another way of stating this "bug" report is that, IMO, entries in.chezmoiremove
should be implicitly ignored, as well.To reproduce
Expected behavior
foo
should not appear in the diff.Why?
Of course, there are more complex cases where the correct behavior is not so clear. What if we list a file in
.chezmoiremove
that is within anexact_
directory?# .chezmoiremove foo/bar
but
IMO, the behavior of
.chezmoiremove
here should mirror that of.chezmoiignore
—which currently ignores the listed file and generates a non-exact copy of the directoryfoo
.Output of command with the
--verbose
flagOutput of
chezmoi doctor
Additional context
N/A
The text was updated successfully, but these errors were encountered: