FR: allow `target-arch` of `arm64` in addition of `aarch64` in archive names

[ilyagr]

I'm having trouble setting up binstall for https://github.com/drdo/redu/releases because
their archives for ARM systems end with redu-0.2.12-darwin-arm64.bz2 while binstall expects redu-0.2.12-darwin-aarch64.bz2. The { target-arch }

I might be able to convince them to rename the archive, but still, it would be nice if binstall tried that automatically. Even internally, binstall often calls the architecture arm64.

I think I could work around this by setting up [package.metadata.binstall.overrides.XXXXXX] for each arm64 binary, but that seems annoying (though maybe).

A fancier, and not necessarily better, solution would be to allow conditionals in templates in https://github.com/cargo-bins/cargo-binstall/blob/main/SUPPORT.md

[NobodyXu]

I am a bit reluctant to add more of that, the resolution is already quite slow now (and even need github access token to speedup).

I think maybe changing the pkg-url specifcally for aarch64-apple-darwin is better in this case?

Or, we could add simple ternary operator } target-arch == 'aarch64' ? 'arm64' : target-arch } support to leon, but that will be quite complicated and against the goal of leon (simple and fast)

[ilyagr]

Overall, I'm not sure what's best, but here are some thoughts.

I think maybe changing the pkg-url specifically for aarch64-apple-darwin is better in this case?

This would also need to apply to Windows-ARM and Linux-ARM, so it'd be three overrides.

I am a bit reluctant to add more of that, the resolution is already quite slow now (and even need github access token to speedup).

I think "arm64" might be common enough to make it worth it. I am worried about this a bit in the context of #2119 though (I guess specifying the pkg-fmt could be required in that case).

Or, we could add simple ternary operator } target-arch == 'aarch64' ? 'arm64' : target-arch } support to leon, but that will be quite complicated and against the goal of leon (simple and fast)

Another option that comes to mind is allowing one to specify target-arch-mapping = { aarch64 = "arm64" }. This could be generalized to something like:

[package.metadata.binstall.definitions]
my-target-arch.source = "target-arch"
my-target-arch.mapping = { aarch64 = "arm64" }

[NobodyXu]

I think maybe we can have an target-arch-alias

Another option that comes to mind is allowing one to specify target-arch-mapping = { aarch64 = "arm64" }. This could be generalized to something like:

This also sounds good, cc @passcod wdyt?

[passcod]

Oh, as a generalised template variable definition/mapping? That sounds good yeah.