Numpy >= 1.13, matplotlib >=2.0 for astropy 3.1

[mhvk]

As discussed on the mailing list, for 3.1 we may want to depend on numpy >=1.13, since this allows much better performance for Quantity (and thus coordinates, etc.) because it introduced __array_ufunc__. This PR removes the stuff needed for numpy < 1.13.

Note that with this PR, 3.1 will likely only be compatible with numpy 1.13 and 1.14, so 2 versions, though 1.15 would presumably be around the corner by then.

fixes #7545

[astropy-bot]

Hi there @mhvk 👋 - thanks for the pull request! I'm just a friendly 🤖 that checks for issues related to the changelog and making sure that this pull request is milestoned and labeled correctly. This is mainly intended for the maintainers, so if you are not a maintainer you can ignore this, and a maintainer will let you know if any action is required on your part 😃.

Everything looks good from my point of view! 👍

If there are any issues with this message, please report them here.

[bsipocz]

(a minor note for the above, we can obviously make most efforts to be np 1.15 compatible even if that release is not out, and add any necessary fixes for full compatibility in a 3.1.x bugfix)

[astrofrog]

I think you need to also update __minimum_numpy_version__ in astropy/__init__.py

[astrofrog]

Do you mean <1.13?

[mhvk]

OK, thanks, now fixed. I don't know how to change the circleci setup - I think we need a new image? Also, the matplotlib 1.5 failure is odd. It brings up a question of whether we should still support that, or make 3.1 a fairly clean break with old cruft. (E.g., could go for scipy >= 1.0 as well...)

[astrofrog]

@mhvk - can you rebase? We now have an updated CircleCI configuration, so hopefully this will be fixed.

[mhvk]

@astrofrog - OK, rebased. Hopefully tests still pass!

[astrofrog]

@mhvk - a few small comments:

• Can you change astropy/image-tests-py35-mpl153:1.0 to astropy/image-tests-py35-mpl153:1.1 in .circleci/config.yml? (I updated Numpy in there). Also,

• If I try and run python setup.py install, I get the following rather obscure message:

NotImplementedError: __array_wrap__ should not be used with a context any more, since we require numpy >=1.13.  Please raise an issue on https://github.com/astropy/astropy

Can you move:

if not _ASTROPY_SETUP_:
    _check_numpy()

sooner in astropy/__init__.py?

• For the failing Travis build, I think there's a chance this could be real and is due to remaining open files. I wonder if something has changed with Numpy memory mapping. Pinging @drdavella. I wonder whether this would be fixed by Force garbage collection to avoid issues with memory-mapped arrays. pytest-openfiles#7?

• There is a residual Numpy 1.12 build on Travis.

[mhvk]

@astrofrog - I made most of the smaller changes, but do not understand where you would like me to move the numpy check in __init__.py - it already is just after the required part that defines whether or not we're in setup.

[mhvk]

@astrofrog - mpl153 is failing. Do you have any idea? It does seem related to something in numpy.

[astrofrog]

@mhvk - can you try changing to 1.2? I think that should hopefully fix it.

[mhvk]

OK, changed (merged into last commit).

[mhvk]

@astrofrog - the 153 circle-io file still seems to use numpy < 1.13... I think that failure also explains your earlier comment that it would be nice if the error message was clearer -- somehow get_package_info() seems to require importing more than perhaps it should? I must admit being somewhat at a loss...

[astrofrog]

I can investigate this during the week of March 19th

[mhvk]

Rebased, in part to see if the mpl153 got magically resolved... (though I still think it is fine to start requiring matplotlib >=2.0 for astropy 3.1)

[astrofrog]

I agree about requiring Matplotlib >= 2.0, as 1.5 is reasonably ancient now. The issue is indeed that the docker image uses Numpy 1.10

[mhvk]

@saimn - very strange. The only thing I noticed about it, is that it still uses matplotlib 1.5, which should not be there. Running it again without that, just in case it makes a difference.

[mhvk]

@saimn - it was a matter of assuming dict-like .values() have guaranteed order...

[mhvk]

The coverage failure is, I think, just because quite a number of lines got removed.

@astrofrog - anything remaining here?

[bsipocz]

@mhvk - I agree to ignore coveralls, it complains about dropped coverage in generated c code, but then there is no diff for those, so difficult to do anything really.

[mhvk]

@astrofrog, are you happy with this as is?

[mhvk]

@astrofrog - I looked again at this move to numpy 1.13, and do think it is all OK. Could you have a look or dismiss your review and ask someone else?

[astrofrog]

Nice cleanup!

[pllim]

I'm merging this now to simplify work of integrating with Python 3.7. Thanks!