Skip to content

Latest commit

 

History

History
253 lines (166 loc) · 6.91 KB

INSTALL.rst.txt

File metadata and controls

253 lines (166 loc) · 6.91 KB
Raw

Building and installing SciPy

See https://www.scipy.org/Installing_SciPy/

Contents

INTRODUCTION

It is strongly recommended that you use either a complete scientific Python distribution or binary packages on your platform if they are available, in particular on Windows and Mac OS X. You should not attempt to build SciPy if you are not familiar with compiling software from sources.

Recommended distributions are:

The rest of this install documentation does summarize how to build Scipy. Note that more extensive (and possibly more up-to-date) build instructions are maintained at http://scipy.org/scipylib/building/index.html

PREREQUISITES

SciPy requires the following software installed for your platform:

  1. Python 2.7 or >= 3.4
  1. NumPy >= 1.7.1
  1. If you want to build the documentation: Sphinx >= 1.2.1
  1. If you want to build SciPy master or other unreleased version from source (Cython-generated C sources are included in official releases): Cython >= 0.22

Windows

Compilers

There are two ways to build Scipy on Windows:

  1. Use Intel MKL, and Intel compilers or ifort + MSVC. This is currently the most robust method.
  2. Use MingwPy. This is a GCC toolchain that will be used in the future to distribute Scipy binaries on PyPi. See the MingwPy website for details.

Mac OS X

Compilers

It is recommended to use gcc or clang, both work fine. Gcc is available for free when installing Xcode, the developer toolsuite on Mac OS X. You also need a fortran compiler, which is not included with Xcode: you should use a recent gfortran from an OS X package manager (like Homebrew).

Please do NOT use gfortran from hpc.sourceforge.net, it is known to generate buggy scipy binaries.

Blas/Lapack

Mac OS X includes the Accelerate framework: it should be detected without any intervention when building SciPy.

Linux

Most common distributions include all the dependencies. You will need to install a BLAS/LAPACK (all of ATLAS, OpenBLAS, MKL work fine) including development headers, as well as development headers for Python itself. Those are typically packaged as python-dev

INSTALLING SCIPY

For the latest information, see the web site:

https://www.scipy.org

Development version from Git

Use the command:

git clone https://github.com/scipy/scipy.git

cd scipy
git clean -xdf
python setup.py install --user

Documentation

Type:

cd scipy/doc
make html

From tarballs

Unpack SciPy-<version>.tar.gz, change to the SciPy-<version>/ directory, and run:

python setup.py install --user

This may take several minutes to half an hour depending on the speed of your computer. To install to a user-specific location instead, run:

python setup.py install --prefix=$MYDIR

where $MYDIR is, for example, $HOME or $HOME/usr.

** Note 1: On Unix, you should avoid installing in /usr, but rather in /usr/local or somewhere else. /usr is generally 'owned' by your package manager, and you may overwrite a packaged Scipy this way.

TESTING

To test SciPy after installation (highly recommended), execute in Python

>>> import scipy
>>> scipy.test()

To run the full test suite use

>>> scipy.test('full')

Please note that you must have version 1.0 or later of the 'nose' test framework installed in order to run the tests. More information about nose is available on the website.

COMPILER NOTES

You can specify which Fortran compiler to use by using the following install command:

python setup.py config_fc --fcompiler=<Vendor> install

To see a valid list of <Vendor> names, run:

python setup.py config_fc --help-fcompiler

IMPORTANT: It is highly recommended that all libraries that scipy uses (e.g. BLAS and ATLAS libraries) are built with the same Fortran compiler. In most cases, if you mix compilers, you will not be able to import Scipy at best, have crashes and random results at worst.

UNINSTALLING

When installing with python setup.py install or a variation on that, you do not get proper uninstall behavior for an older already installed Scipy version. In many cases that's not a problem, but if it turns out to be an issue, you need to manually uninstall it first (remove from e.g. in /usr/lib/python3.4/site-packages/scipy or $HOME/lib/python3.4/site-packages/scipy).

Alternatively, you can use pip install . --user instead of python setup.py install --user in order to get reliable uninstall behavior. The downside is that pip doesn't show you a build log and doesn't support incremental rebuilds (it copies the whole source tree to a tempdir).

TROUBLESHOOTING

If you experience problems when building/installing/testing SciPy, you can ask help from scipy-user@scipy.org or scipy-dev@scipy.org mailing lists. Please include the following information in your message:

NOTE: You can generate some of the following information (items 1-5,7) in one command:

python -c 'from numpy.f2py.diagnose import run; run()'

  1. Platform information:

    python -c 'import os, sys; print(os.name, sys.platform)'
uname -a
OS, its distribution name and version information
etc.

  2. Information about C,C++,Fortran compilers/linkers as reported by the compilers when requesting their version information, e.g., the output of

    gcc -v
g77 --version

  3. Python version:

    python -c 'import sys; print(sys.version)'

  4. NumPy version:

    python -c 'import numpy; print(numpy.__version__)'

  5. ATLAS version, the locations of atlas and lapack libraries, building information if any. If you have ATLAS version 3.3.6 or newer, then give the output of the last command in

    cd scipy/Lib/linalg
python setup_atlas_version.py build_ext --inplace --force
python -c 'import atlas_version'

  1. The output of the following commands

    python INSTALLDIR/numpy/distutils/system_info.py

    where INSTALLDIR is, for example, /usr/lib/python3.4/site-packages/.

  2. Feel free to add any other relevant information. For example, the full output (both stdout and stderr) of the SciPy installation command can be very helpful. Since this output can be rather large, ask before sending it into the mailing list (or better yet, to one of the developers, if asked).

  3. In case of failing to import extension modules, the output of

    ldd /path/to/ext_module.so

    can be useful.