Anaconda and upgrading to new M1 Mac

Question

Background

I've just got a new M1 mac mini dev machine, and migrated from my old x86 mac using apple's migration assistant.

Doing that also copied over all my conda environments to the new machine (they were all in my home directory)

I installed the latest version of anaconda and anaconda plus all my python code and environments seem to work fine (this includes a bunch of wheel modules, notably numpy/scipy).

I did a bunch of googling for my questions below, but couldn't find any good answers anywhere - so I thought I'd ask SO as this seems like a quite common situation others will run into

Questions

• Does anyone know the status of M1 native versions of python/numpy/scipy etc provided by conda forge?
• I presume that all the binaries in my environments for python/numpy etc all still the old x86 versions, as they were all in environments in my home directory, and running via emulation. So, how do you go about changing/updating those to a M1 arm native version if/when available?

Solution 1

A quick update as of July 2021.

TLDR

• The conda-forge group have a M1 native conda installer here.
• Installation is simple - run the installer, and you have conda up and running.
• This will install an M1 native conda, and that conda's default environment will by default install M1 native python versions and M1 native versions of modules (if available).
• There seem to be native osx M1 native wheels for most common modules now available on the conda-forge channel.

Current status

It seems Anaconda still do not have a native M1 version, nor does Miniconda. ...I can't figure out why it's taken so long and neither still seem to have native M1 support, but that's a separate issue.

Alternative

However, as steff above mentioned, conda-forge (as in the group responsible for maintaining the conda-forge channel) do have a installer for their version of conda that is itself both native M1, and also sets up your environment to pull M1 native wheels where available. This they call Miniforge.

Their github is here.

Various installers for their Miniforge (via direct download, curl or homebrew) can be found on their github page (above) - the direct link to the ARM native miniforge installer is here.

A quick search on conda-forge show's almost all common modules do now have native M1 wheels available. (look for supporting platform 'osx-arm64` eg numpy)

Caveats

I've not tested this too extensively yet, and I'm not sure exactly what happens if a non-M1 wheel is available (I believe it will default to downloading a no-arch version).

I'm also not sure/haven't tested whether you can mix and match M1 wheels with x86 mac wheels. (I'm guessing this would work, but haven't tried).

I also have only done minimal testing using the conda's pip, and how well it recognizes/tries to download/resolves M1 vs x86 pip packages.

Solution 2

The answer here is going to evolve over time, so here is the most up-to-date knowledge I have as of 27 Jan 2021.

Installing conda in emulation mode works completely fine. All you need to do is to install it in a Terminal run in emulation mode, or else install it using a Terminal emulator that has not been ported over yet.

Once your conda environments are up and running, everything else looks and feels like it did on x86 Macs.

If you'd like a bit more detail, I blogged about my experience. Hopefully it helps you here.

Solution 3

I got my M1 about 2 weeks ago and managed to install absolutely everything I need natively from conda-forge and pip. The installer you can download here. As of 5Feb Homebrew is also officially supported on osx-arm64.

Comments

[Richard]

Thanks - I ended up just going with the emulation route you did, as I didn't want to deal with potential compatibility issues of a non-ananconda miniconda like you ran into. It all works fine for me right now, except I don't see anyway yet to see if python or modules are ARM or x86.

[ericmjl]

My pleasure. To respond to your follow-up point, most Python modules are pure Python, so they will only require the Python interpreter to work, and the backing ARM/x86 architecture won't matter. The only places where it does matter is if there are C extensions that are needed, I think. (JAX, as I mentioned in my blog post, is one example.)

[Richard]

A lot of the modules I use that are the bottlenecks are compiled ...numpy, scipy etc - so it would be great to get native versions of those - but even better have conda check the arch automatically and install the appropriate ones for you

[John Laudun]

The blog post was extremely useful. As a long-time user of MacPorts, it's going to hurt letting go, but it's time to try mini condo, and I will probably still use MP for things like wget, etc.

[user13985]

I will be instaling miniconda for my Macbook M1. What is emulation mode? What's wrong if I just followed miniconda website? docs.conda.io/en/latest/miniconda.html

[mathandy]

TensorFlow (except apple version of 2.4) does not work. It's the only library or app I've had trouble with so far. Importing gives an "illegal hardware instruction" error. Based on the solutions I'm seeing, "tensorflow<2.4" may not work on apple m1 anytime soon.

[stephinity]

@user13985 I believe ericmjl means running the x86 version on the M1 using Apple's Rosetta "emulator". See apple.com for details.

[user13985]

@stephinity that’s what I think too. Then, it’s not really taking an advantage of the M1 chip

[Stuart Berg]

"I believe it will default to downloading a no-arch version." Huh? Most packages are either arch-specific or no-arch, not both.

[Stuart Berg]

I doubt that wheels for x86 and M1 could be mixed. If they contain any compiled code, then they couldn't be used together. Apple's docs say: "The system prevents you from mixing arm64 code and x86_64 code in the same process."

[Stuart Berg]

For context on what it took for the conda-forge team to get a build working, read this page. Sounds like it was a heroic effort, but they had to use some non-standard tricks to get it all to work.

[Richard]

If you install the arm64 (M1) version, then it will install either arm64 wheels, or failing that noarch.

[Richard]

Yes - I confirmed on the conda forge github site, you cannot run both arm64 and x86 modules at the same time. However, the conda-forge install does let you install both x86 and arm64 environments at the same time, and you can swap back and forth when you need to.

[Phani Teja]

Has there been any recent developments in M1 ? Are scikit, tensorflow and keras natively available on M1?

[Richard]

not sure on TF and keras, but most of just about anything else is native if you conda-forge. ...I'd guess both of the other two are now as well.

[mmmmmm]

@StuartBerg Apple's compiler and linker have always allowed you to have multiple architectures in one binary see the lipo command . What the docs mean is that Intel code can't call Arm code and vice versa. When the object is loaded the system chooses one architecture out of those in the binary

[Admin]

As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.

[avivr]

@Richard you mentioned that "the conda-forge install does let you install both x86 and arm64 environments at the same time". How does one do this? Is there a way to specify the arch when creating each env?

[Richard]

@avivr Sorry for the late reply. It's not too hard, but it isn't really well documented anywhere. I based mine on this: github.com/Haydnspass/…. Basically you need to set your CONDA_SUBDIR variable before creating a new environment. In my .bashrc I have the following two aliases set to do that: alias conda-arm='conda env config vars set CONDA_SUBDIR=osx-arm64' and alias conda-x86='conda env config vars set CONDA_SUBDIR=osx-64'

[Richard]

@avlvr So for example, with those aliases, to create/use an x86 env I would a) conda create new_env, b) conda activate new_env c) conda_x86 d) re-install/install python and packages