Expose alternate architecture naming to chezmoi data

[felipecrs]

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

I use .chezmoiexternal.* to install some packages from outside into my home folder. To give an example, consider this archive which contains the kubectx binary:

https://github.com/ahmetb/kubectx/releases/download/v0.9.4/kubectx_v0.9.4_linux_x86_64.tar.gz

As you can see, it uses x86_64 as the architecture naming, as opposed to the one within .chezmoi.arch.

Describe the solution you'd like

Maybe to have .chezmoi.altArch with x86_64?

Describe alternatives you've considered

It's not difficult to work around this issue, I can add this to my .chezmoi.yaml.tmpl:

data:
  uname_arch: "{{ output "uname" "-m" | trim }}"

Additional context

Given that the alternative is quite simple, I'm just sharing the idea wondering if you think it's worth adding to chezmoi or not.

[twpayne]

The tricky bit here is that every operating system and distribution has variations in how it names the architecture. For example, Go uses 386,.deb-based distributions use i386, and .rpm-based distributions use i686. There are similar variations for amd64, and it gets really really messy when you start getting into the ARM architecture variants.

Similarly, different software uses different names for operating systems, for example you might see windows, Win10, Win64, Windows, etc.

Basically, it's very hard to chezmoi to provide any sort of canonical translation here, as there is simply no consistency in the world, and I would rather provide no solution than an incomplete solution that will invariably break in various cases. As you identify. this can be solved by using some logic in the config file template.

Another possible work-around for this is to add a mapping to .chezmoidata, for example if you put the following in .chezmoidata.yaml:

architectures:
  amd64:
    deb: amd64
    kubectx: x86_64
    rpm: x86_64

you can then use something like (warning: untested):

{{ (index .architectures .chezmoi.arch).kubectx }}

to get the string that kubectx uses instead of amd64.

[felipecrs]

Thanks, that's fair enough. How about a new entry named .chezmoi.uname, similar to .chezmoi.osRelease, which contains uname reported data? Like all or some of these:

❯ uname --help
Usage: uname [OPTION]...
Print certain system information.  With no OPTION, same as -s.

  -a, --all                print all information, in the following order,
                             except omit -p and -i if unknown:
  -s, --kernel-name        print the kernel name
  -n, --nodename           print the network node hostname
  -r, --kernel-release     print the kernel release
  -v, --kernel-version     print the kernel version
  -m, --machine            print the machine hardware name
  -p, --processor          print the processor type (non-portable)
  -i, --hardware-platform  print the hardware platform (non-portable)
  -o, --operating-system   print the operating system
      --help     display this help and exit
      --version  output version information and exit

So that one could use {{ .chezmoi.uname.machine }} if that's what is needed.

[felipecrs]

Since the alternative is quite compelling, I'm closing this issue. Feel free to reopen or create another if you think .chezmoi.uname is worth implementing. Thanks!