python builds on win-arm64
conda-forge now has partial experimental support for Windows on Arm64 platform. To use the conda-forge packages on an arm64 machine running windows, you first have to install Miniforge for Windows x86_64 since miniforge does not support Windows arm64 yet. Then you can do
set "CONDA_SUBDIR=win-arm64"
conda create -n newenv python
conda activate newenv
This gives you a minimal python environment. You can play around with this untested python binary and provide feedback.
Here's some thoughts on the development so far:
On conda-forge CI, we are cross-compiling builds for win-arm64 from win-64 platform. Therefore these are untested so far. Microsoft has generously donated VMs for these packages to be tested, but they are not setup yet as we need more support in conda/conda-build.
When bootstrapping a new platform, we first cross-compile from another platform until we get to a point where we have conda, conda-build, and build-tools like ninja. This lets us run conda-build natively on the new platform and we do not need cross-compilation anymore. On osx-arm64, we kept on doing cross-compilation as we did not have any CI for osx-arm64 natively.
For win-arm64 we do have VMs donated by Microsoft, but we are not at the point where we have conda, conda-build and build-tools like ninja built yet. That requires more support for cross-compilation on windows in conda-forge as most of our infrastructure is focused on UNIX-like platforms. For example: cross-python package is a series of hacks that are hung together by a thread to make cross-compiling work since python does not support cross-compiling by default. It'd be quite a lot of work to make it work on windows.
Some build systems like autotools do work, but it was a challenge to get things like CC_FOR_BUILD working since usually Visual Studio only keeps one VS build system active at one time. This was fixed by calculating paths manually to set CC_FOR_BUILD. Another issue was that some build systems don't really like spaces in the path of the compiler in CC_FOR_BUILD. This was fixed by creating virtual drive to avoid spaces.
Some packages do require MinGW gcc builds, but upstream support for Windows on Arm64 platform is still not complete.
We have a migration for windows-arm64 platform in the conda-forge status page. Currently we only try to build conda,conda-build,mamba,rattler-build and pixi as given in the explicit list.
Looking at the graph, there are nodes that are clearly unneeded for the packages given in the list. Help is welcome to debug the bot on trimming down the graph here so we can focus on the packages actually needed for getting the build tools out.
