SciPy build/install Mac Osx

Your problem is that you need to install a Fortran compiler to build scipy.

Also, if you already have a numpy that’s built with Fortran support disabled, you may have to replace it. Some of Apple’s pre-installed Python versions have such a numpy build pre-installed.

---

The easiest way to get Fortran is with Homebrew. As the docs say, you need to install Xcode and its Command Line Tools first. (The way to install the Command Line Tools changes with almost each major version of Xcode, so see the linked docs for an up-to-date explanation.) Then install Homebrew. The installation URL has changed a few times, so see the Homebrew home page or installation instructions(http://brew.sh/), but it will be something like:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Then:

brew install gcc

(Note that until some time in 2014, gfortran was a separate recipe from gcc, so the command was brew install gfortran. But if you try that now, you’ll get an error saying “GNU Fortran is now provided as part of GCC, and can be installed with: brew install gcc“.)

---

You really want to use pip to install scipy, so if you don’t have that, get it first. Apple’s pre-installed Python, at least in 10.7 and 10.8, includes easy_install but not pip, so the easiest way to do that is:

sudo easy_install pip

However, you may want to consider using a virtualenv instead of a global install (in which case you also want to remove the sudo on the following commands).

Now that you’ve got gfortran and pip, all you have to do is this:

sudo pip install --upgrade numpy
sudo pip install scipy

---

Caveats:

• The instructions above are for Apple’s pre-installed version(s) of Python. If you’re using a different version of Python, you really should consider not doing so. Keeping the paths, installed packages, etc. in sync is a nightmare. The exception to this is if you want a Python 3.x version, in which case installing it from python.org or Homebrew is perfectly reasonable. There will be no collisions, because python, pip2.7, etc. will be for Apple’s Python; python3, pip3.3, etc. for the 3.x version.

• If you already have pip, but fear it may be out of date, pip install --upgrade pip. (Besides the security and robustness benefits, this may save you a whole lot of time by making you compatible with binary wheels for some of the scientific stack or other modules.)

• For most non-Apple Python installations (and maybe even Apple’s in 10.9 or 10.10; I haven’t checked), you should not use easy_install to install pip. Follow the pip install instructions. But first make sure you don’t already have it.

  • If you’re using virtualenv/venv, your virtual environments will already include pip.
  • Python 3.4 or later may (and will, if from a python.org installer) include a pip bootstrap. If your 3.4+ doesn’t already have pip, you may want to python -m ensurepip to install it.
  • Some third-party installs, like Homebrew or ActiveState, include pip.

• For Python 3.3 or later, you may want to use the built-in venv instead of virtualenv.

• If you’re using MacPorts, Fink, gentoo-alt, etc., you should install the scipy package that comes with your package manager, and it will drag in whatever else it needs (maybe even including rebuilding Python and GCC).

• Third-party binary installs like Enthought and ActiveState may already include scipy and everything else you need. If not, the instructions are basically the same as above, but you’ll have to guess which steps to skip or follow, whether to sudo, etc.

---

If you’re using a non-Apple build of Python 2.7, and you want to avoid the PATH problems, you have to do two things:

First, do not, ever, install any Python packages that include scripts or binaries (including pip itself) in more than one Python. For example, if you install ipython for both Apple 2.7 and Homebrew 2.7, both will attempt to create scripts named /usr/local/bin/ipython and /usr/local/bin/ipython-2.7. If you’re lucky, one install will fail. Otherwise, they’ll both succeed, one will end up overwriting the other, and you will have no way of running the overwritten version.

Second, make sure the path to the alternate Python’s scripts and binaries comes before Apple’s in the PATH. Depending on which alternate Python you’ve installed and which instructions you followed, this could be:

• /usr/local/bin
• /Library/Frameworks/Python.framework/Versions/2.7/bin
• /usr/local/share/python2.7/bin
• /usr/local/Cellar/python/2.7.3/bin
• something else

Whatever the path is, you need to edit your PATH variable.

If you want to affect GUI apps (and LaunchAgents, etc.), there is apparently no longer a supported way to do this, but the deprecated QA1067 does seem to still work in Lion. It’s also what the Homebrew FAQ and Python FAQ suggest.

If you only care about command-line sessions (both Terminal.app and remote ssh), you can instead just do the standard Unix thing of editing the appropriate profile file. Which profile file is appropriate depends on what you want to affect. (All users or just one user? bash or any shell? And so on.) If you don’t know which one you want, you really should do some research. If you don’t want to bother learning, just do ~/.profile and then don’t complain if it wasn’t what you wanted.

Either way, you need to make sure that the appropriate path comes before /usr/bin in the PATH. So, for example, you could add the following to ~/.profile:

PATH=/usr/local/bin:$PATH
export PATH

(You will of course need to either create a new Terminal shell, or source the script, before it takes effect.)

If you’re using homebrew, brew doctor will tell you if you got it right.