Stickiness of architecture is a change from how Rosetta worked in the PowerPC to Intel transition: in macOS Big Sur child processes will prefer the arch of the parent process if one is available to maximize compatibility. So for example launching x86_64 sh will cause a python invocation from that shell to also be x86_64.
The "arch" utility is your escape hatch to switch the preferred arch for the spawned process and all of its children.
Homebrew maintainer here. We don’t officially support Big Sur yet, but installing it via Rosetta will cause it to fetch x86 bottles instead of ARM ones. At least, that’s the plan.
Off-topic: Thanks for working on Homebrew btw! It just occurred to me that I've never donated despite using it so much but now I have. Link for others:
Seemed to work fine for me... I'm now trying to install both versions of brew and spin up terminal sessions accordingly.
Are these 'good practices' for Arm Macs?:
1) When spinning up an iTerm session, figure out if it's 'Darwin x86_64' or 'Darwin arm64' - and configure paths accordingly. so they use the right brew binaries.
2) Easily double check what version of a running package/keg based on what arch is displayed in Activity Monitor.
3) That way, you can just use brew with Rosetta to start (which I did) then build up native arm Brew over time. and let the Rosetta brew fall away.
Casks are typically precompiled application binaries, and I assume most applications (that choose to support M1) will be Universal Binaries soon. Casks would not need to change anything.
> Homebrew maintainer here. We don’t officially support Big Sur yet, but installing it via Rosetta will cause it to fetch x86 bottles instead of ARM ones. At least, that’s the plan.
It will create X86 binaries instead of ARM ones. (which might be a plus at the current moment)
The "arch" utility is your escape hatch to switch the preferred arch for the spawned process and all of its children.