Is this a good approach to enable disable features on Chezmoi?

[lnyousif]

So I decided to use a features tags in my .chezmoi.toml.tmpl

something like

features.personal = {{ $personal }} 
features.powerful = {{ $powerful }}
features.headless = {{ $headless }}
features.ephemeral = {{ $ephemeral }}

first is there a better way to do the above ?

in my .chezmoiignore

I added this

{{ range $key, $value := .features }}
{{ if eq $value false -}}
.chezmoiscripts/{{ $.chezmoi.os }}/features/{{ $key }}/**
{{ end -}}
{{ end -}}

now inside .chezmoiscripts

I have 3 folders darwin, linux and windows
inside each there is a features folder and inside it i create a folder that have the feature name , the above .ignore file ignores any feature that is false and that make enabling features so much easier an streamlined.

Any issues you see with this approach and can I improve on it ?

[halostatue]

I have started using a role test for some of my work. I’m not completely happy with it, because I am using it on data pulled from 1Password and I want to be able to indicate "this can be used with any role" and so far, that just means ["*"] in the roles list in the data.

All that to say, what you're doing will work - but you might want to consider a tag-like approach instead. That is (using your boolean questions):

features = {{
  list (and $personal 'personal')
       (and $powerful 'powerful')
       (and $headless 'headless')
       (and $ephemeral 'ephemeral')
  | compact }}

Then in .chemzoiignore:

{{- /* assume that `.all_features` has the list of all feature keys supported */ -}}
{{ range $key, $_ := .all_features }}
{{   if has $key .features }}.chezmoiscripts/{{ $.chezmoi.os }}/features//{{ $key }}/** }}{{ end }}
{{ end }}

[lnyousif]

Thank you, I guess your approach is cleaner
but should this line
{{ if has $key .features }}.chezmoiscripts/{{ $.chezmoi.os }}/features//{{ $key }}/** }}{{ end }}

be more like
{{ if NOT has $key .features }}.chezmoiscripts/{{ $.chezmoi.os }}/features//{{ $key }}/** }}{{ end }}
or am I missing something?

PS: The reason its boolean , as its part of the init process to give me a choice when I setup the machine

[halostatue]

Thank you, I guess your approach is cleaner but should this line {{ if has $key .features }}.chezmoiscripts/{{ $.chezmoi.os }}/features//{{ $key }}/** }}{{ end }}

be more like {{ if NOT has $key .features }}.chezmoiscripts/{{ $.chezmoi.os }}/features//{{ $key }}/** }}{{ end }} or am I missing something?

You are correct. It should be {{ if not (has $key .features) }}…{{ end }} (I don't know if not is strict about receiving one argument or whether it can receive a pipeline, but the parentheses ensure that it receives one argument.)

PS: The reason its boolean , as its part of the init process to give me a choice when I setup the machine

There's a few ways to do that, and I preserved the boolean selection, but used the boolean values to produce the list with (and $powerful "powerful"). There is a flaw with my approach in that it will replace all values that aren't matched with false. This could be fixed with or (and $powerful "powerful") "", but this starts getting a little hard to read. (It would be a little easier to read as $powerful | and "powerful" | or "", but …)

What might be nice to have is new init prompt functions, promptChoiceList{,Once} that return a list of selected options from a choice list (charm implemented this in gum as gum choose https://github.com/charmbracelet/gum/blob/main/choose/choose.go).

I’m still not sure which is better, but I like the idea of a feature list or a role list.

[lnyousif]

I feel like the features approach may allow a good grouping and folders approach that allow the same dotfiles repo to serve setup that can be for a family, Like I have 2 Fedora machines for my 2 kids that would allow me to easily reproduced without managing another repo.

I like the neatness of your approach but I think mine is a bit more easier to read and modify. I still would like a better way than features. [prop name]

https://github.com/charmbracelet/gum/blob/main/choose/choose.go).
love this

[Lockszmith-GH]

For a family approach check out #2574, it's a layered approach I've come up with for a team environment.