After a prior topic/discussion on issues regarding Anaconda installation on Windows Snapdragon/ARM systems, it was noted that Anaconda is shooting for a Q4 release of a native Snapdragon version.
Upon some thinking, while this is great, I’m wondering if it’ll probably be best to continue to run the x64 Anaconda version in emulation for a while.
When conda (before it was fixed) was incorrectly identifying the platform as Win-Arm64, it was clear that there were a lot of packages that were unavailable on ARM64 (presumably because they included pre-compiled binaries that were unavailable for ARM64), including conda.
Given that, I’m thinking that, at least for a while, running Anaconda on Snapdragon natively will result in a lot of unavailable packages until the authors provide native ARM64 versions (which may take a while). Therefore, running Anaconda x64 in emulation may be initially preferable.
One thought, is it possible, with the Anaconda ARM64 version to create an environment that will run in x64 emulation? On Snapdragon we don’t really have the ability to turn emulation on or off, I believe it self-identifies when it is needed, and I’m not sure how it decides that.
On package availability — one correction that changes the calculus: for conda packages, we build the win-arm64 builds ourselves. You’re not waiting on individual package authors the way you would be with PyPI wheels. main/win-arm64 is publishing actively today across Python 3.12–3.14, and in several cases conda has win-arm64 builds where native wheels don’t exist yet — cryptography, shapely, sqlalchemy and asyncpg among them.
There is a shorter list where upstream itself is the blocker and we can’t get ahead of it. We will have documentation including guidance to users here along with the emulation strategies mentioned below.
We already have 70% of package coverage for win-arm64 compared to win-64. Our goal is to enable a majority of use cases to be run natively by the time we launch the Miniconda installer. However, you are correct there will be a tail of things we will continue to work on building out post the initial launch.
On emulation — you will have a few options here, we are working on adding more information to our documentation ahead of the launch to make sure this is clear for all users.
In short,
Stay fully emulated — the win-64 installer, as you’re doing now.
Go native, and flip the whole install to x64 if you need to: conda config --set subdir win-64.
Mixed, which is likely what you actually want: a native install with specific environments created as x64.
This is native conda functionality, not a workaround. conda annotates the environment with that target, so later installs into it keep resolving win-64. You can’t retrofit --platform onto an existing environment — it’s create-time only.
