Is it possible to request an x86_64 download while on an ARM Mac?

[DavisVaughan]

Consider the following

arch -x86_64 curl -LsSf https://github.com/posit-dev/air/releases/latest/download/air-installer.sh | sh
downloading air 0.2.0 aarch64-apple-darwin
skipping sha256 checksum verification (it requires the 'sha256sum' command)
installing to /Users/davis/.local/bin
  air
everything's installed!

I was actually expecting to get the x86_64-apple-darwin binary here, but I think this part of the installer script thwarts this

cargo-dist/cargo-dist/templates/installer/installer.sh.j2

Lines 946 to 958 in 318d14d

	if [ "$_ostype" = Darwin ] && [ "$_cputype" = i386 ]; then
	# Darwin `uname -m` lies
	if sysctl hw.optional.x86_64 | grep -q ': 1'; then
	_cputype=x86_64
	fi
	fi
	if [ "$_ostype" = Darwin ] && [ "$_cputype" = x86_64 ]; then
	# Rosetta on aarch64
	if [ "$(sysctl -n hw.optional.arm64 2>/dev/null)" = "1" ]; then
	_cputype=aarch64
	fi
	fi

At least, that's my understanding based on comparing this output to the script

In my use case, I have a github actions script that is supposed to be downloading the x86_64 and aarch64 artifacts from the release page to be bundled into a VS Code extension
https://github.com/posit-dev/air/blob/dde788fe6a840bd63854c082eff062c44d086ea1/.github/workflows/release-vscode.yml#L28-L52

It currently doesn't work right because I forgot to specify with arch -x86_64 curl vs arch -arm64 curl, but it seems like based on my above experience that also won't do the right thing because the installer script "sees through" the arch -x86_64 and downloads the ARM build anyways.

So, I guess the question is: How could I download the x86_64 build on arm mac?

[DavisVaughan]

Looks like this was intentional (and recent) from
#941

I wonder if we could have a way to opt out of this? Unfortunately github doesn't provide a pure intel mac runner, so it will always be an ARM mac that this call is run from

[ashleygwilliams]

hey @DavisVaughan ! thank you so much for the detailed issue, i think your conclusion is correct that it forces the intel installer. i hadn't considered your usecase but it makes sense! my initial thought is that we might want to introduce an env var that can force the arch (similar to ones we support for install location)... do you think that would work?

if you'd be interested in contributing we'd happily mentor you on how to do it!

[DavisVaughan]

I thought about this a bit more and realized that it is possible we were sort of abusing cargo-dist's intended purpose here.

AFAICT, cargo-dist's main purpose is to help get you set up to run the tool, and in that case I think outsmarting Rosetta emulation as cargo-dist currently does is probably the right move. In our particular case, we were just using the installer script as a really smart and easy file downloader, which helped us then bundle the binary into the right place. It was fairly easy to reproduce that ourselves, since we know which platform we are downloading for already posit-dev/air#201.

I looked at the shell installers a bit more and I'm not even entirely sure what the environment variable would look like. Would it be unix only? It seems like on windows there are quite a few architectures to pick from (

cargo-dist/cargo-dist/templates/installer/installer.ps1.j2

Lines 179 to 185 in f5d0250

	switch ($p.GetValue($null).ToString())
	{
	"X86" { return "i686-pc-windows" }
	"X64" { return "x86_64-pc-windows" }
	"Arm" { return "thumbv7a-pc-windows" }
	"Arm64" { return "aarch64-pc-windows" }
	}

), would they all be allowed? If you used the environment variable to download and install one of those architectures that isn't actually compatible with your OS, it seems like that would be bad and against the ethos of cargo-dist.

So all in all I'm mostly convinced this was us just using it wrong. I'll let you all decide if you want to keep this issue open or not! Thanks for the quick response though!

[duckinator]

I think it makes sense for cargo-dist to download the native version whenever possible, given that the goal of the installers is to install it for the system.

It might make more sense for downloading the files to be done via a small independent tool. Downloading archives from GitHub and optionally extracting some common formats (at least .zip, .tar.gz, .tar.xz) can definitely be done entirely in Rust.

(I've made a tool for downloading files from GitHub Releases before, but it's in Python, and it looks like your project already involves 3 languages -- so I can't say I'd recommend it.)

Unless such a tool exists as an executable that doesn't need a separate runtime, I think the change you made is probably the best option.

[duckinator]

I'm going to go ahead and close this since it seems like the best answers are "use curl/tar/unzip" or "make a separate tool".

[DavisVaughan]

Agreed @duckinator, thanks for taking a look!