Only Python 3.5 wheel built, and against the wrong numpy version

[rgommers]

I just followed the instructions in the README (push an empty commit), and the build seems to be configured to only build on Python 3.5 right now. And it does that against the very latest numpy -pip install --upgrade numpy has been added to .travis.yml, which is wrong.

[rgommers]

Due to 51276f8. @matthew-brett can we revert that? And is the 3.5 build now working with some version of numpy, or should we stick to 2.7/3.3/3.4 only for now?

I've tagged 0.16.1, so I'd like to resolve this tomorrow.

[rgommers]

I see 1.9.3 is the earliest numpy version with wheels for Python 3.5. So I guess we need to build against that.

I've pushed a revert in 13562a6, can always be undone again. I'll see if the 3.5 build works, but otherwise I'll just upload the 2.7/3.3/3.4 ones to PyPi and announce the release.

[rgommers]

Results at https://travis-ci.org/MacPython/scipy-wheels/builds/87286625

The 3.4 build actually worked, but we see one RuntimeWarning in the tests that's converted to an error.

The 3.5 build didn't start, because the nipy server doesn't have numpy 1.9.3. Will look at what it does have.

[rgommers]

It has 1.9.2, so try that. The issue with the 3.4 build is the upgrade to numpy 1.10.1 which errors on warnings. So try using 1.9.2 for that as well.

[rgommers]

The 3.5 build against numpy 1.9.2 failed with a compile error. So 1.10.1 it is? Kind of tricky, because there's a numpy 1.9.3 wheel on PyPi and we don't force the use of >=1.10.1 for the scipy wheel.

[matthew-brett]

I pushed an attempt to build against numpy 1.7.1 - that the NIPY server does have, and removing the --no-index to allow pypi - maybe that helps?​

[rgommers]

Interesting, that worked. I'm quite surprised that that even builds, because numpy 1.7.1 was released a couple of years before Python 3.5. It's seems Python 3.x has stabilized a lot.

Also weird then that building against numpy 1.9.2 is broken. I can have a look if I can reproduce that. But this wheel should be good to go. Thanks @matthew-brett

[matthew-brett]

I seem to remember that most recent numpies depend on later gfortran - is that right? Then the build will break with this gfortran which is the trusty old gcc 4.2 dual arch build. Building with later gcc is quite a bit more involved because of changing licenses, and lack of dual-arch support, but I guess we'll have to do that in due course.

[rgommers]

Right, forgot about that. If the need comes up soon, I suspect that fixing up gfortran 4.2 support in numpy is a lot easier that moving to a newer compiler. IIRC the breaking change was pretty simple.