OK to upload patched 1.9.2 for Python 3.5?
Hi,
I'm just building numpy 1.9.2 for Python 3.5 (just released).
In order to get the tests to pass on Python 3.5, I need to cherry pick commit 7d6aa8c onto the 1.9.2 tag position.
Does anyone object to me uploading a wheel built from this patched version to pypi as 1.9.2 for Python 3.5 on OSX? It would help to get the ball rolling for Python 3.5 binary wheels.
Cheers,
Matthew
On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett matthew.brett@gmail.com wrote:
Hi,
I'm just building numpy 1.9.2 for Python 3.5 (just released).
In order to get the tests to pass on Python 3.5, I need to cherry pick commit 7d6aa8c onto the 1.9.2 tag position.
Does anyone object to me uploading a wheel built from this patched version to pypi as 1.9.2 for Python 3.5 on OSX? It would help to get the ball rolling for Python 3.5 binary wheels.
Why not releasing this as 1.9.3 ? It does not need to be a full release (with binaries and all), but having multiple sources for a given tag is confusing.
David
Cheers,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi,
On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau cournape@gmail.com wrote:
On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett matthew.brett@gmail.com wrote:
Hi,
I'm just building numpy 1.9.2 for Python 3.5 (just released).
In order to get the tests to pass on Python 3.5, I need to cherry pick commit 7d6aa8c onto the 1.9.2 tag position.
Does anyone object to me uploading a wheel built from this patched version to pypi as 1.9.2 for Python 3.5 on OSX? It would help to get the ball rolling for Python 3.5 binary wheels.
Why not releasing this as 1.9.3 ? It does not need to be a full release (with binaries and all), but having multiple sources for a given tag is confusing.
Generally OK with me, but it's quite a bit of extra work for very little gain. We'd have to tag, release a source tarball and OSX wheels, at least.
The patch being cherry-picked is just deleting some legacy monkey-patching of gzip:
https://github.com/numpy/numpy/commit/7d6aa8c721d5274ac57d0c87685d472cb1fd79...
and it's difficult for me to imagine this could cause a problem with source differences.
Cheers,
Matthew
On Mon, 14 Sep 2015 01:32:13 -0700 Matthew Brett matthew.brett@gmail.com wrote:
Does anyone object to me uploading a wheel built from this patched version to pypi as 1.9.2 for Python 3.5 on OSX? It would help to get the ball rolling for Python 3.5 binary wheels.
Why not releasing this as 1.9.3 ? It does not need to be a full release (with binaries and all), but having multiple sources for a given tag is confusing.
Generally OK with me, but it's quite a bit of extra work for very little gain. We'd have to tag, release a source tarball and OSX wheels, at least.
It's always bad to have two silent versions of a single release. People can never know up front which version they got, since it's not written anywhere. That's why the right policy is to bump the version number in some way (be it by incrementing it or adding a ".patchXXX" at the end).
Regards
Antoine.
On Mon, Sep 14, 2015 at 9:32 AM, Matthew Brett matthew.brett@gmail.com wrote:
Hi,
On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau cournape@gmail.com
wrote:
On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett matthew.brett@gmail.com wrote:
Hi,
I'm just building numpy 1.9.2 for Python 3.5 (just released).
In order to get the tests to pass on Python 3.5, I need to cherry pick commit 7d6aa8c onto the 1.9.2 tag position.
Does anyone object to me uploading a wheel built from this patched version to pypi as 1.9.2 for Python 3.5 on OSX? It would help to get the ball rolling for Python 3.5 binary wheels.
Why not releasing this as 1.9.3 ? It does not need to be a full release (with binaries and all), but having multiple sources for a given tag is confusing.
Generally OK with me, but it's quite a bit of extra work for very little gain. We'd have to tag, release a source tarball and OSX wheels, at least.
I think it's highly desirable that we also have a *source* release that builds on Python 3.5, irrespective of whether or not we have binary wheels for a couple of platforms up for Python 3.5. So I would encourage a quick 1.9.3 release that incorporates this patch.
-- Robert Kern
I would like to add patches for the mingwpy windows build as well. There is no Python-3.5 build so far.
Carlkl
2015-09-14 10:46 GMT+02:00 Robert Kern robert.kern@gmail.com:
On Mon, Sep 14, 2015 at 9:32 AM, Matthew Brett matthew.brett@gmail.com wrote:
Hi,
On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau cournape@gmail.com
wrote:
On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett <
matthew.brett@gmail.com>
wrote:
Hi,
I'm just building numpy 1.9.2 for Python 3.5 (just released).
In order to get the tests to pass on Python 3.5, I need to cherry pick commit 7d6aa8c onto the 1.9.2 tag position.
Does anyone object to me uploading a wheel built from this patched version to pypi as 1.9.2 for Python 3.5 on OSX? It would help to get the ball rolling for Python 3.5 binary wheels.
Why not releasing this as 1.9.3 ? It does not need to be a full release (with binaries and all), but having multiple sources for a given tag is confusing.
Generally OK with me, but it's quite a bit of extra work for very little gain. We'd have to tag, release a source tarball and OSX wheels, at least.
I think it's highly desirable that we also have a *source* release that builds on Python 3.5, irrespective of whether or not we have binary wheels for a couple of platforms up for Python 3.5. So I would encourage a quick 1.9.3 release that incorporates this patch.
-- Robert Kern
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
as due to the many incompatiblities in 1.10 many will likely not be able to update anytime soon, so I think putting out another 1.9.3 bugfix release would be a good idea. I can probably do the release management for it, though I haven't been keeping up with bugfixes recently so, please comment on important issues you would want fixed. The np.where upcast regression and np.nanmedian issues come to my mind as should be fixed.
On 09/14/2015 11:21 AM, Carl Kleffner wrote:
I would like to add patches for the mingwpy windows build as well. There is no Python-3.5 build so far.
Carlkl
2015-09-14 10:46 GMT+02:00 Robert Kern <robert.kern@gmail.com mailto:robert.kern@gmail.com>:
On Mon, Sep 14, 2015 at 9:32 AM, Matthew Brett <matthew.brett@gmail.com <mailto:matthew.brett@gmail.com>> wrote: > > Hi, > > On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau <cournape@gmail.com <mailto:cournape@gmail.com>> wrote: > > > > > > On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett <matthew.brett@gmail.com <mailto:matthew.brett@gmail.com>> > > wrote: > >> > >> Hi, > >> > >> I'm just building numpy 1.9.2 for Python 3.5 (just released). > >> > >> In order to get the tests to pass on Python 3.5, I need to cherry pick > >> commit 7d6aa8c onto the 1.9.2 tag position. > >> > >> Does anyone object to me uploading a wheel built from this patched > >> version to pypi as 1.9.2 for Python 3.5 on OSX? It would help to get > >> the ball rolling for Python 3.5 binary wheels. > > > > > > Why not releasing this as 1.9.3 ? It does not need to be a full release > > (with binaries and all), but having multiple sources for a given tag is > > confusing. > > Generally OK with me, but it's quite a bit of extra work for very > little gain. We'd have to tag, release a source tarball and OSX > wheels, at least. I think it's highly desirable that we also have a *source* release that builds on Python 3.5, irrespective of whether or not we have binary wheels for a couple of platforms up for Python 3.5. So I would encourage a quick 1.9.3 release that incorporates this patch. -- Robert Kern _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org <mailto:NumPy-Discussion@scipy.org> http://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Sep 14, 2015 at 3:47 AM, Julian Taylor jtaylor.debian@googlemail.com wrote:
as due to the many incompatiblities in 1.10 many will likely not be able to update anytime soon, so I think putting out another 1.9.3 bugfix release would be a good idea. I can probably do the release management for it, though I haven't been keeping up with bugfixes recently so, please comment on important issues you would want fixed. The np.where upcast regression and np.nanmedian issues come to my mind as should be fixed.
OK - fair enough - it would be good to do this soon as possible, as Python 3.5 is currently the default download from the Python.org site (rather than Python 2.7) and most other binary installers depend on numpy. Is there anything I can do to help?
Matthew
On Mon, Sep 14, 2015 at 9:42 AM, Matthew Brett matthew.brett@gmail.com wrote:
On Mon, Sep 14, 2015 at 3:47 AM, Julian Taylor jtaylor.debian@googlemail.com wrote:
as due to the many incompatiblities in 1.10 many will likely not be able to update anytime soon, so I think putting out another 1.9.3 bugfix release would be a good idea. I can probably do the release management for it, though I haven't been keeping up with bugfixes recently so, please comment on important issues you would want fixed. The np.where upcast regression and np.nanmedian issues come to my mind as should be fixed.
OK - fair enough - it would be good to do this soon as possible, as Python 3.5 is currently the default download from the Python.org site (rather than Python 2.7) and most other binary installers depend on numpy. Is there anything I can do to help?
For example, how about a rush-out 1.9.3 release with just the gzip patch, and a very-soon release with further patches?
Matthew
On 9/14/2015 3:47 AM, Julian Taylor wrote:
as due to the many incompatiblities in 1.10 many will likely not be able to update anytime soon, so I think putting out another 1.9.3 bugfix release would be a good idea. I can probably do the release management for it, though I haven't been keeping up with bugfixes recently so, please comment on important issues you would want fixed. The np.where upcast regression and np.nanmedian issues come to my mind as should be fixed.
On 09/14/2015 11:21 AM, Carl Kleffner wrote:
I would like to add patches for the mingwpy windows build as well. There is no Python-3.5 build so far.
Carlkl
2015-09-14 10:46 GMT+02:00 Robert Kern <robert.kern@gmail.com mailto:robert.kern@gmail.com>:
On Mon, Sep 14, 2015 at 9:32 AM, Matthew Brett <matthew.brett@gmail.com <mailto:matthew.brett@gmail.com>> wrote: > > Hi, > > On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau <cournape@gmail.com <mailto:cournape@gmail.com>> wrote: > > > > > > On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett <matthew.brett@gmail.com <mailto:matthew.brett@gmail.com>> > > wrote: > >> > >> Hi, > >> > >> I'm just building numpy 1.9.2 for Python 3.5 (just released). > >> > >> In order to get the tests to pass on Python 3.5, I need to cherry pick > >> commit 7d6aa8c onto the 1.9.2 tag position. > >> > >> Does anyone object to me uploading a wheel built from this patched > >> version to pypi as 1.9.2 for Python 3.5 on OSX? It would help to get > >> the ball rolling for Python 3.5 binary wheels. > > > > > > Why not releasing this as 1.9.3 ? It does not need to be a full release > > (with binaries and all), but having multiple sources for a given tag is > > confusing. > > Generally OK with me, but it's quite a bit of extra work for very > little gain. We'd have to tag, release a source tarball and OSX > wheels, at least. I think it's highly desirable that we also have a *source* release that builds on Python 3.5, irrespective of whether or not we have binary wheels for a couple of platforms up for Python 3.5. So I would encourage a quick 1.9.3 release that incorporates this patch. -- Robert Kern
Support for Visual Studio 2015 and Intel Fortran 16 for Python 3.5 on Windows would also be nice.
I am using:
DEV: Replace deprecated options for ifort https://github.com/numpy/numpy/pull/5555
remove /GL for vs2015 in check_long_double_representation https://github.com/numpy/numpy/pull/6096
Enable Visual Studio 2015 C99 features https://github.com/numpy/numpy/pull/6141
BLD: revert C99 complex for msvc14 https://github.com/numpy/numpy/pull/6171
Christoph
Hi Christoph,
On Mon, Sep 14, 2015 at 11:06 AM, Christoph Gohlke cgohlke@uci.edu wrote:
On 9/14/2015 3:47 AM, Julian Taylor wrote:
as due to the many incompatiblities in 1.10 many will likely not be able to update anytime soon, so I think putting out another 1.9.3 bugfix release would be a good idea. I can probably do the release management for it, though I haven't been keeping up with bugfixes recently so, please comment on important issues you would want fixed. The np.where upcast regression and np.nanmedian issues come to my mind as should be fixed.
On 09/14/2015 11:21 AM, Carl Kleffner wrote:
I would like to add patches for the mingwpy windows build as well. There is no Python-3.5 build so far.
Carlkl
2015-09-14 10:46 GMT+02:00 Robert Kern <robert.kern@gmail.com mailto:robert.kern@gmail.com>:
On Mon, Sep 14, 2015 at 9:32 AM, Matthew Brett <matthew.brett@gmail.com <mailto:matthew.brett@gmail.com>> wrote: > > Hi, > > On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau<cournape@gmail.com mailto:cournape@gmail.com> wrote: > > > > > > On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett <matthew.brett@gmail.com mailto:matthew.brett@gmail.com> > > wrote: > >> > >> Hi, > >> > >> I'm just building numpy 1.9.2 for Python 3.5 (just released). > >> > >> In order to get the tests to pass on Python 3.5, I need to cherry pick > >> commit 7d6aa8c onto the 1.9.2 tag position. > >> > >> Does anyone object to me uploading a wheel built from this patched > >> version to pypi as 1.9.2 for Python 3.5 on OSX? It would help to get > >> the ball rolling for Python 3.5 binary wheels. > > > > > > Why not releasing this as 1.9.3 ? It does not need to be a full release > > (with binaries and all), but having multiple sources for a given tag is > > confusing. > > Generally OK with me, but it's quite a bit of extra work for very > little gain. We'd have to tag, release a source tarball and OSX > wheels, at least.
I think it's highly desirable that we also have a *source* release that builds on Python 3.5, irrespective of whether or not we have binary wheels for a couple of platforms up for Python 3.5. So I would encourage a quick 1.9.3 release that incorporates this patch. -- Robert KernSupport for Visual Studio 2015 and Intel Fortran 16 for Python 3.5 on Windows would also be nice.
I am using:
DEV: Replace deprecated options for ifort https://github.com/numpy/numpy/pull/5555
remove /GL for vs2015 in check_long_double_representation https://github.com/numpy/numpy/pull/6096
Enable Visual Studio 2015 C99 features https://github.com/numpy/numpy/pull/6141
BLD: revert C99 complex for msvc14 https://github.com/numpy/numpy/pull/6171
Would you mind making a branch for these, preferably starting from my current branch:
git://github.com/matthew-brett/numpy.git branch prepare-1.9.3 ?
I had a quick go, but the merge conflicts needed more understanding than I had of the Windows build.
Thanks a lot,
Matthew
participants (7)
-
Antoine Pitrou -
Carl Kleffner -
Christoph Gohlke -
David Cournapeau -
Julian Taylor -
Matthew Brett -
Robert Kern