.chezmoiinittemplates

[halostatue]

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

I'm working on some complex feature requests that will make my .chezmoi.toml.tmpl much harder to read, so I was going to put these fragments in .chezmoitemplates, but the presence of promptChoice or any of the other prompt functions makes these unable to be moved.

It would be useful to be able to have reusable templates for init-mode when adding complex logic like this (yes, it works; 1p/accounts/list isn't yet visible on my site, but it basically returns op accounts list --format json):

{{- /*
     * Configure 1Password accounts. This is more complex than the previous promptString
     * mechanism used previously, because we want to force an alias when a new account is
     * added.
     */ -}}
{{-
    $opAccounts := includeTemplate "1p/accounts/list" .
      | fromJson | jq "map(.url)" | first
-}}
{{- $op := get . "op" -}}
{{- $excluded := get $op "_excluded" | default list -}}
{{- $included := omit $op "_excluded" | values }}
{{- range $_, $url := $opAccounts -}}
{{-   if or (has $url $excluded) (has $url $included) }}{{ continue }}{{ end -}}
{{-   $choice := promptChoice (printf "Configure %s" $url) (list "alias" "exclude" "skip") -}}
{{-   if eq $choice "alias" -}}
{{-     $alias := promptString (printf "Alias for %s" $url) -}}
{{-     if hasKey $op $alias -}}
{{-       warnf "Alias %s already is linked to %s; skipping" $alias (get $op $alias) -}}
{{-     else -}}
{{-       $op = set $op $alias $url -}}
{{-     end -}}
{{-   else if eq $choice "Exclude"  -}}
{{-     $excluded = append $excluded $url -}}
{{-   end -}}
{{- end -}}
{{- if gt (len $excluded) 0 -}}
{{-   $op = set $op "_excluded" $excluded -}}
{{- end -}}
{{- toJson $op -}}

Describe alternatives you've considered

Putting the templates at the top of my .chezmoi.toml.tmpl.

[twpayne]

It would be useful to be able to have reusable templates for init-mode when adding complex logic like this

Does this complex logic really have to live in the init template?

[halostatue]

I’m not sure I understand the question. I recently completed this and started using it yesterday, but it's a refactoring of something I was managing poorly manually. A lot of this was enabled by the addition of promptMultichoice, because I can now have more control over how things are set up. (You can look at the old version .chezmoi.toml.tmpl@837800c, an even older version .chezmoi.toml.tmpl@6552458, and compare it to the newest version .chezmoi.toml.tmpl@0505f3a5.

I’m now having to configure things very differently than my last job to where the work computer doesn't have a lot of software that I use at home, and my home computer doesn't have some of the software on the work computer. There's the work that I did for git identities (to keep git identity configuration out of the main configuration file and using include templates that involve parsing 1Password documents from YAML, etc.). But the initial setup is always a little hard, so I’ve decided to sort on available 1Password document tags for some features, as well as being able to configure the map of 1Password accounts that are in use.

This particular piece works so that if you add a new 1Password account to op, you will be prompted on the next chezmoi init to categorize that account, and you can choose to alias (add to the map), exclude (never asks again), or skips (asks on the next chezmoi init.

[twpayne]

Wow, that's a really sophisticated and impressive setup!

I would like to keep the config file template generation mechanism simple, if possible. This is why I'm pushing back on the .chezmoiinittemplates idea.

As an alternative, what do you think about making the config file generation mechanism pluggable? i.e. instead of chezmoi executing the .chezmoi.toml.tmpl template to generate your config file, you could instead run any command you wanted to generate your config file? This would give you full flexibility to use your favorite fully-powered language of choice, instead of having to shoe-horn a complex setup into Go's text/template language.

Thoughts?

[halostatue]

chezmoi provides so many useful tools (like promptMultichoiceOnce) that would have to be recreated in any other language, and any other integration with chezmoi data and/or templates (like my programs template) would present different issues.

At the same time…that sort of pluggability would let me skip some of the inanities forced by using text/template as a full programming language.

I don't know that I’d want to develop everything that I would be missing, and my setup works, but because I can't use includeTemplate, it means that the config template is very large.

I don't think that there's a good answer for this, because .chezmoiinittemplates would only be available when using init or --init, which complicates that flow.