Group multiple files by target

[arhuman]

Being able to have target that groups several files would be much more convenient:

Having:
git/dot_gitignore
git/dot_gitconfig
zsh/dot_zshrc

Instead of:
dot_gitignore
dot_gitconfig
dot_zshrc

would allow :
chezmoi list to provide a less cluterred result:
git
zsh

and allow simpler command

chezmoi apply git would apply all the files associated to git (you don't even need to remember which ones)

This would "just" require one more level to store the target name.
The target name could be deduced from the file added (removing trailing 'rc' or 'config') or passed with a --target flag
chezmoi add ~/.bashrc => target deduced 'bash'
chezmoi add --target=shell ~/.bashrc => target specified 'shell'

[Lockszmith-GH]

Interesting idea, how would these 'deduced' groups be maintained?

How will the source state look like with mixed targeted and untargeted files?

How will the source dir distinguish between a regular directory and a target group?

[halostatue]

As @Lockszmith-GH suggests, this is a very interesting idea, but it's mostly unworkable.

• Deduced Groups: There are no reliable heuristics for deduction given Chezmoi's wide platform support and general agnosticism toward application support. You can use mackup and chezmoi has an undocumented and mostly unsupported mackup command (chezmoi help mackup) for some level of integration. See common config locations #1747, Supports predefined configuration file paths, shares the fruits of labor, and saves a lot of time! #3370 (comment) for more information.

• Top Level Directories as Groups: Chezmoi is built around the assumption that the source directory (either the same as the working tree or the relative directory in .chezmoiroot) is a mirror of $HOME or %userprofile% on Windows. This would completely break that assumption and be a major engineering effort for something of niche benefit. There's also cross-group contamination that would need to be considered.

  Those last two items might not be obvious, so let me explain:

  • Niche benefit: I don't think that most people who use chezmoi would use such groups. I can't see saying chezmoi apply group:git when I could just to chezmoi apply ~/.config/git. It might be slightly more interesting to do chezmoi apply group:vim if you're still using an older vim configuration (~/.vimrc, ~/.gvimrc, ~/.vim) rather than nvim or vim9 with xdg-ish support (~/.config/nvim or ~/.config/vim, respectively).

  • Cross-group contamination: Right now, one is guaranteed‡ that a target file will appear exactly once in the chezmoi source directory. With groups, I could add ~/.bashrc to both a bash group and a sdkman (java version manager) group because sdkman modifies ~/.bashrc. State management here would be an absolute nightmare.

In all, I don't think this is a workable idea. But if we were to consider it, there are a couple of options.

• Add a new group_ attribute that could only be set on directories. This would sort of work like you suggest, but would act a bit more like a specialized .chezmoiroot per-group. There would need to be some checks to ensure that ~/.bashrc cannot be added to more than one group (including the "default" unnamed group).
• In the discussed but currently unplanned chezmoi v3 with a configuration file, add some sort of tagging mechanism so that directories or individual files could be tagged from the configuration file. Then you could do chezmoi apply --tag=bash.

You could simulate some of this manually — but would probably give up on it fairly quickly because it would involve a lot of extra work — with an extreme version of @Lockszmith-GH's layered configuration approach (#2574). Such layering has its place, but isn't really workable beyond a couple of layers because of the overhead involved.

‡ Modulo some issues with externals like ohmyzsh. I think that's a problem with how those externals are engineered, personally, but chezmoi still has tools to work around them even if they are unobvious.

[twpayne]

To build upon what Locksmith-GH and halostatue have already said, I consider grouping files by target to be an anti-feature and will not implement it.

The primary reason is the "cross-group contamination" issue that halostatue identifies. Groups might seem initially simple, but you very quickly encounter files that need to be members of multiple groups. Shell and editor configs are the most obvious examples. See https://www.chezmoi.io/user-guide/frequently-asked-questions/design/#can-chezmoi-support-multiple-sources-or-multiple-source-states.

If you really want to do this, you can achieve the same effect with templates.

[Lockszmith-GH]

Hope this didn't kill the vibe for you.
It's just, sometimes ideas on the surface have some appeal.

But implementation is hard, or at least it is hard doing it right.

There is a subset of your idea that I like, but I think implementation needs to be thoroughly thought of.

[halostatue]

I think that the concept of tags could be very interesting -- and can definitely be done with templates. I'm doing something similar with my files for package management, but I have a few places where I'm using the same tags to render configuration templates separately.

[arhuman]

Thanks you for your insightful answers.
I totally missed the "cross-group contamination" and the FAQ about the multiple sources statement.

No your answers definitely "didn't kill the vibe", chezmoi is a great tool, far more advanced than the custom one I made, but I was just hoping for the only feature that I use missing in chezmoi.
Seems I'll have to get out of my "habit zone" and consider the chezmoi way of doing things.

[halostatue]

To elaborate on the tags approach that I mentioned.

Because this is mostly for package management, I call the tags that I use roles. I set them during chezmoi init with the new promptMultichoiceOnce init function:

{{/* https://github.com/halostatue/dotfiles/blob/main/home/.chezmoi.toml.tmpl#L42-L45 */}}
{{- $computerRoles = concat $computerRoles $opts -}}
{{- $roles := promptMultichoiceOnce . "roles" "What roles does this computer serve" $computerRoles -}}
{{- if has "Skip" $roles }}{{ $roles = "" -}}
{{- else if has "None" $roles }}{{ $roles = list }}{{ end -}}

There are more of these that I use (AWS roles, Git identities), but this is the main one.

I then use these -- mostly as {{- $work := has "work" (get . "roles" | default list) -}} in a few different templates:

• https://github.com/halostatue/dotfiles/blob/3876bc3aacb5c453e951de06157b4aaa0fc06cd3/home/private_Library/Application%20Support/private_Code/User/settings.json.tmpl
• https://github.com/halostatue/dotfiles/blob/3876bc3aacb5c453e951de06157b4aaa0fc06cd3/home/private_dot_npmrc.tmpl
• https://github.com/halostatue/dotfiles/blob/3876bc3aacb5c453e951de06157b4aaa0fc06cd3/home/private_dot_cargo/liner.toml.tmpl
• https://github.com/halostatue/dotfiles/blob/3876bc3aacb5c453e951de06157b4aaa0fc06cd3/home/private_dot_config/ghostty/config.tmpl
• https://github.com/halostatue/dotfiles/blob/3876bc3aacb5c453e951de06157b4aaa0fc06cd3/home/private_dot_config/mise/config.toml.tmpl

One could take advantage of such tag-like things and chezmoi's "do not render an empty file" behaviour to do something like:

{{- if not (has "git" (get . "roles" (default list))) -}}
# ~/.git/config or ~/.gitconfig
{{- end -}}

This would not render your git configuration unless you chose a git role for the machine.

This won't work on a per-apply basis (and you wouldn't want it to do so, because that would result in inconsistent state), but you could have featuresets for rendering entire configurations.