Consider current arch when constructing install_path

[iilyak]

Is your feature request related to a problem? Please describe

On Mac M1 architecture if you need to compile for x86 you are forced into having two parallel installation of tools. In homebrew the problem is solved with having two prefixes:

/usr/local for x86 tools /opt/homebrew for m1 tools

The correspondent architecture is chosen via one of the following tricks

0. Prefix each command with arch -x86_64 <full_path_to_command> [arguments]
1. Clone iTerm application and configure a clone to be executed using rosetta2
2. Use on iTerm and then run a shell compiled for specific architecture
   • arch -x86_64 /usr/local/bin/fish
   • arch arm64 /opt/homebrew/bin/fish

Since asdf uses the same location for all tools without considering current architecture it is only usable in one world either arm64 or x86_64.

If I install let's say erlang using asdf while I am on m1 architecture and then switch into x86 shell my installation wouldn't work. I would have to delete the installation and install it again for x86. This is not a viable solution because erlang installs via compilation from source. Which takes from 20-40 minutes.

Describe the proposed solution

Modify install_path to include architecture. Currently install path is constructed as see here

{asdf_data_dir}/installs/{plugin}/{version}"

This can be changed to

{asdf_data_dir}/installs/{plugin}/{arch}/{version}"

Where {arch} would be determined by output of uname -m (or arch). However arch is more precise which might be not the best case for asdfs use case. The arch distinguish the following architectures:

• i386 - 32-bit intel
• x86_64 - 64-bit intel
• x86_64h - 64-bit intel (haswell)
• arm64 - 64-bit arm
• arm64e - 64-bit arm (Apple Silicon)

Describe similar asdf features and why they are not sufficient

There might be a way to use https://github.com/asdf-community/asdf-link plugin to link tools installed via homebrew and specific for current architecture. However this will not work with .tool-versions file. Since it would require all team members to follow manual steps to install correct versions using brew commands. Also it wouldn't allow switching between multiple version of the tools.

Describe other workarounds you've considered

• Patching asdf
• Creating shims in ~/.local/bin
• Abuse dotfile manager to replace links in ~/.local/bin to correct architecture dependent installation. Switching could be done via single command, but multiple architectures in two different terminal tabs couldn't be used.

[jthegedus]

Is this really an issue on any system other than macOS with Apple Silicon and Rosetta 2?

I am inclined to say this is a "won't fix" issue. macOS support for both architectures is a timed event and I am not aware of any other systems this would be necessary for.

[rdgacarvalho]

Any update regarding that issue? I am facing the same problem as @iilyak I am currently working on mac M1 and other mattes on mac Intel and it's a pain to solve/recompile tools back and forth. Thanks

[Stratus3D]

I'm inclined to not address this. I'm working on Mac M1 and haven't had any issues as I alway using arm64 in the shell.

[hyperupcall]

I'm inclined to mark this as a wontfix and close this issue as well. Supporting this would complicate the codebase, (the old and new directory structure must be supported side-by-side) for supporting a transitionary edge-case only present on macOS.

One way to solve this is to have some sort of custom startup script that switches between ASDF_DATA_DIRs, depending on the architecture:

if current_arch_is x86_64; then
  ASDF_DATA_DIR="$HOME/.local/share/asdf_data_dir_x64_64"
else
  ASDF_DATA_DIR="$HOME/.local/share/asdf_data_dir_arm"
fi
source "$HOME/.asdf/asdf.sh"

I know it isn't pretty, but when all applications well-support the M1 architecture, I wouldn't want to be left with this legacy cruft in the codebase.