Speeding up Travis builds for python projects that depend on scipy

.travis.yml

sudo: false                  # ensures the new container based infrastructure is used. 
language: python
cache: 
    directories:
        - $HOME/.cache/pip

python:
- '2.7'
- '3.4'
addons:
  apt:                      # these packages must be installed before scipy can be compiled
    packages:
    - libatlas-base-dev
    - gfortran

before_install:
    - mkdir -p $HOME/.cache/pip/wheels    
    # build wheel only if none present
    - travis_wait pip wheel --find-links=$HOME/.cache/pip/wheels --use-wheel --wheel-dir=$HOME/.cache/pip/wheels scipy
    # now install from it
    - pip install --no-index --find-links=$HOME/.cache/pip/wheels scipy

script:
- nosetests 

travis_scipy.md

In scientific python community, the scipy stack is a very commonly used in many projects. It can be installed via pip, making continuous integration of such projects visa travis quite straightforward. However, since scipy contains a lot of C and fortran modules that must be compiled at installation time, pip install scipy takes a lot of time, adding ~15 minutes to each build.

In fact, scipy installation steps will trigger built timeout in travis by default. This can be avoided by using travis_wait. But this is hardly the desired scenario for continuous integration of most projects.

dan-blanchard has outlined a solution to this problem, by invoking [miniconda] (http://repo.continuum.io/miniconda/index.html) to install the scipy stack. Here I outline an alternate method, using the caching features of the new container-based infrastructure of travis.

All we need to do is

• ask travis to cache the $HOME/.cache/pip directory.
• ask pip to first look for a wheel for scipy first, before attempting to compile it.

Nice @debsankha . So does it compile at all, or just downloads a wheel?

Thanks @andsor. It compiles the wheel if none is present.