MRG: preparations for 1.9.3 release #6332
Conversation
I'm not sure exactly when GzipFile.seek started supporting the whence= argument by default -- sometime around python 2.5 from the looks of http://bugs.python.org/issue1355023. But in any case it was definitely there by 2.6, which is now the earliest version we support, so there's no longer any need to monkeypatch it in. This also fixes an error in python 3.5b2, which I haven't bothered to track down further because these are the wages of monkeypatching.
Ensure that build_ext.include_dirs is the same physical list as build_ext.distribution.include_dirs. Conflicts: numpy/distutils/command/build_ext.py
|
Linux travis build passing. Successful OSX wheel builds : https://travis-ci.org/matthew-brett/numpy-wheels/jobs/81102106 @cgohlke - would you mind testing? |
|
LGTM, do you want to wait on word from @cgohlke before merging? |
|
@cgohlke - do you have time to do the patches? Or should we cut the release like this? Nathaniel - do you think it is reasonable to do a release from this content + / - Windows patches? I believe I have the pypi and github permissions to do the release. |
|
I don't have any objection -- we could debate back and forth if anyone has a favorite bug fix they want to get in, but IMHO the bottom line is that we should get out some kind of 1.9.3 that passes tests on py35, and if you want to do the work then that's fine with me :-). And no-one's objected on the mailing list or #6319, so guess we're good to go. (I'm not worried about getting @carlkl's patches into this -- they can go into 1.10.1 or whatever just as well.) We do need the usual release engineering gunk: updated version in the source code, release notes, tag, etc. -- do you have the permissions for that? |
|
I do have github and pypi write permission, so I can tag the release and upload the source and OSX wheels to pypi. I also have (some) upload permission to sourceforge, but I'm proposing not to do this release on sourceforge, on the basis that sourceforge is mainly for docs and windows builds, and we can't build a Python 3.5 binary using the mingw toolchain. |
|
@cgohlke - I'm planning to release later on today. Do you have time to merge the Windows fixes? |
|
I am trying to work out how to upload packages with a PGP signature. I failed with the following: That generated unsigned packages : https://testpypi.python.org/pypi/numpy/1.9.3 @juliantaylor @pv - any hints how to do that? |
|
Planning to merge - any objections? |
|
Go for it. |
The /Qlowercase and /us options has been deprecated in the Intel Visual Fortran Compiler since at least version 2013. Replace with /names:lowercase and /assume:underscore.
Update pavement.py and setup.py with changes to release versions.
f679cfe to
7f96e9d
Compare
MRG: preparations for 1.9.3 release Backport of 7d6aa8c - gzip fix for Python 3.5 Backport of b08f369 - numpy.distutils patch to help homebrew Backport of various fixes for Windows builds on modern MSVC.
|
I have further patches for mingwpy builds (windows) that could go to maintenance/1.9.x and/or to numpy/master. Any preference, objections? |
|
Carl - both maintenance and master seem like good places for those. Do you mind waiting for the next maintenance release? Is it possible to build numpy for Python 3.5 with your tool-chain? |
|
your 2 questions: python3.5 support is not finished yet. I made import libraries the vcruntime140.dll way (see steve dower's blog) to avoid http://bugs.python.org/issue25027. So extension binaries will be linked against vcruntime140.dll as well as against all the api-ms-win-crt-**-l1-1-0.dll's. Needs still more testing. Concerning numpy-1.9.3: The status for numpy-1.9.2 compiled with mingwpy and OpenBLAS and longdouble faked to double:
I would like to make a PR for numpy:maintenance/1.9.x to get the changes into numpy-1.9.3 |
|
Great progress - thanks a lot. Julian - are you still interested to do a 1.9.4? When would you plan to do that? Carl - could you put in a PR to maintenance/1.9.x so we can get an idea of the extent of the changes? Presumably the 'inf' bug needs to be fixed on the mingw side? |
|
I plan to do the PR to maintenance/1.9.x tomorrow. If needed, I can add another one for numpy/master. |
|
OK - then if you don't mind I will release 1.9.3 today, because otherwise it's going to be another couple of days, to review the PR and accept it. I'm happy to do a quick 1.9.4 release with just these fixes if there is no obvious time-frame for a more substantial 1.9.4 release. |
|
@carlkl Numpy 1.10 will be coming out soon, so a PR for master would be appreciated. That is where PR should normally start. Is there a reason (incomplete, etc) that you are looking at 1.9.3 first? |
|
To answer my own question about signing packages - this works: Signing via |
|
@carlkl @juliantaylor Somewhat off topic, but when you get things figured out we should try to update numpy-vendor to produce 64 bit binaries. |
|
@charris, instead of creating a dedicated numpy-vendor I propose using mingwpy wheels, as described in #6350 (comment) |
|
@carlkl numpy-vendor is a vagrant managed virtual machine that runs WINE on Ubuntu for the Windows compiles, so I assumed that at some point we would want to update the provisioning of the virtual machine and WINE to use your new tool chain. What am I missing? |
|
@charris adding OpenBLAS binaries and the mingwpy wheels should be enough? |
|
Probably. I'm not an expert on this and it isn't pressing, but once 1.10.0 is out we can work on it. |
Backport of 7d6aa8c - gzip fix for Python 3.5
Backport of b08f369 - numpy.distutils patch to help homebrew