Hi All, Julian Taylor has put windows binaries and sources for the 1.8.1 release candidate up on sourceforge<http://sourceforge.net/projects/numpy/files/NumPy/1.8.1rc1/>. If things go well, it will taken to a full release in a week or so. Chuck
On Mo, 2014-03-03 at 09:23 -0700, Charles R Harris wrote:
Hi All,
Julian Taylor has put windows binaries and sources for the 1.8.1 release candidate up on sourceforge. If things go well, it will taken to a full release in a week or so.
Thanks to both of you. Also for sieving through all those issues before :). - Sebastian
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi there! I just tried setting up a new installation using numpy 1.8.1rc1 (+scipy 0.13.3 and matplotlib 1.3.1). I ran into problems when installing matplotlib 1.3.1. The attached logfile shows the full log, but it ends with: src/_png.cpp:329:15: error: 'npy_PyFile_Dup' was not declared in this scope if ((fp = npy_PyFile_Dup(py_file, "rb"))) ^ src/_png.cpp:577:13: error: 'npy_PyFile_DupClose' was not declared in this scope if (npy_PyFile_DupClose(py_file, fp)) { ^ error: command 'x86_64-linux-gnu-gcc' failed with exit status 1 The problem went away (and matplotlib installed cleanly) when I re-did the whole shebang using numpy 1.8.0, so I suspect this was caused by something in the rc. Cheers Thomas On 2014-03-03 17:23, Charles R Harris wrote:
Hi All,
Julian Taylor has put windows binaries and sources for the 1.8.1 release candidate up on sourceforge <http://sourceforge.net/projects/numpy/files/NumPy/1.8.1rc1/>. If things go well, it will taken to a full release in a week or so.
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 3/4/2014 4:49 AM, Thomas Unterthiner wrote:
Hi there!
I just tried setting up a new installation using numpy 1.8.1rc1 (+scipy 0.13.3 and matplotlib 1.3.1). I ran into problems when installing matplotlib 1.3.1. The attached logfile shows the full log, but it ends with:
src/_png.cpp:329:15: error: ‘npy_PyFile_Dup’ was not declared in this scope if ((fp = npy_PyFile_Dup(py_file, "rb"))) ^ src/_png.cpp:577:13: error: ‘npy_PyFile_DupClose’ was not declared in this scope if (npy_PyFile_DupClose(py_file, fp)) { ^ error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
The problem went away (and matplotlib installed cleanly) when I re-did the whole shebang using numpy 1.8.0, so I suspect this was caused by something in the rc.
Cheers
Thomas
This error is known and expected. It is due to an API change in a semi-private numpy header and it is fixed in matplotlib master and v1.3.x. <https://github.com/numpy/numpy/pull/4152> <https://github.com/numpy/numpy/pull/4214> <https://github.com/matplotlib/matplotlib/pull/2705> Christoph
On 04.03.2014 18:08, Christoph Gohlke wrote:
On 3/4/2014 4:49 AM, Thomas Unterthiner wrote:
Hi there!
I just tried setting up a new installation using numpy 1.8.1rc1 (+scipy 0.13.3 and matplotlib 1.3.1). I ran into problems when installing matplotlib 1.3.1. The attached logfile shows the full log, but it ends with:
src/_png.cpp:329:15: error: ‘npy_PyFile_Dup’ was not declared in this scope if ((fp = npy_PyFile_Dup(py_file, "rb"))) ^ src/_png.cpp:577:13: error: ‘npy_PyFile_DupClose’ was not declared in this scope if (npy_PyFile_DupClose(py_file, fp)) { ^ error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
The problem went away (and matplotlib installed cleanly) when I re-did the whole shebang using numpy 1.8.0, so I suspect this was caused by something in the rc.
Cheers
Thomas
This error is known and expected. It is due to an API change in a semi-private numpy header and it is fixed in matplotlib master and v1.3.x.
<https://github.com/numpy/numpy/pull/4152> <https://github.com/numpy/numpy/pull/4214> <https://github.com/matplotlib/matplotlib/pull/2705>
hm breaking released matplotlib is bad, I though matplotlib didn't use that function, I could have sworn I checked that. I guess we will have to revert this change to an internal duplicate.
Hi, I built (and tested) some numpy wheels for the rc1: http://nipy.bic.berkeley.edu/numpy-dist/ Cheers, Matthew
Hi, On Wed, Mar 5, 2014 at 3:29 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I built (and tested) some numpy wheels for the rc1:
Now building, installing, testing, uploading wheels nightly on OSX 10.9: http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7 http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3 and downloading, testing built wheels on OSX 10.6: http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7-downloaded http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3-downloaded Chuck - are you release manager for this cycle? Would you mind sending me your public ssh key so I can give you access to the buildbots for custom builds and so on? Cheers, Matthew
On Wed, Mar 5, 2014 at 7:28 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Wed, Mar 5, 2014 at 3:29 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I built (and tested) some numpy wheels for the rc1:
Now building, installing, testing, uploading wheels nightly on OSX 10.9:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7 http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3
and downloading, testing built wheels on OSX 10.6:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7-downloaded http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3-downloaded
Chuck - are you release manager for this cycle? Would you mind sending me your public ssh key so I can give you access to the buildbots for custom builds and so on?
Cheers,
Julian has done most of the work for 1.8.1. I did the 1.8.0 release because it needed doing, but building releases isn't my strong point and Ralf actually did the builds for that. So I'll happily send you my ssh, but either Ralph or Julian might be a better bet for getting the work done :) Chuck
On Thu, Mar 6, 2014 at 10:35 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Wed, Mar 5, 2014 at 7:28 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Wed, Mar 5, 2014 at 3:29 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I built (and tested) some numpy wheels for the rc1:
Now building, installing, testing, uploading wheels nightly on OSX 10.9:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7 http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3
and downloading, testing built wheels on OSX 10.6:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7-downloaded http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3-downloaded
Chuck - are you release manager for this cycle? Would you mind sending me your public ssh key so I can give you access to the buildbots for custom builds and so on?
Cheers,
Julian has done most of the work for 1.8.1. I did the 1.8.0 release because it needed doing, but building releases isn't my strong point and Ralf actually did the builds for that. So I'll happily send you my ssh, but either Ralph or Julian might be a better bet for getting the work done :)
Or, I might add, yourself, if you are interested in taking over that role. Chuck
Hi, On Thu, Mar 6, 2014 at 9:37 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Mar 6, 2014 at 10:35 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Wed, Mar 5, 2014 at 7:28 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Mar 5, 2014 at 3:29 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I built (and tested) some numpy wheels for the rc1:
Now building, installing, testing, uploading wheels nightly on OSX 10.9:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7 http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3
and downloading, testing built wheels on OSX 10.6:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7-downloaded http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3-downloaded
Chuck - are you release manager for this cycle? Would you mind sending me your public ssh key so I can give you access to the buildbots for custom builds and so on?
Cheers,
Julian has done most of the work for 1.8.1. I did the 1.8.0 release because it needed doing, but building releases isn't my strong point and Ralf actually did the builds for that. So I'll happily send you my ssh, but either Ralph or Julian might be a better bet for getting the work done :)
Or, I might add, yourself, if you are interested in taking over that role.
I don't know the code well enough to be the release manager, but I'm very happy to do the OSX binary builds. So - release manager VP of OSX maybe? Cheers, Matthew
On Thu, Mar 6, 2014 at 12:05 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Thu, Mar 6, 2014 at 9:37 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Mar 6, 2014 at 10:35 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Wed, Mar 5, 2014 at 7:28 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Mar 5, 2014 at 3:29 PM, Matthew Brett <matthew.brett@gmail.com
wrote:
Hi,
I built (and tested) some numpy wheels for the rc1:
Now building, installing, testing, uploading wheels nightly on OSX
10.9:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7 http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3
and downloading, testing built wheels on OSX 10.6:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7-downloaded
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3-downloaded
Chuck - are you release manager for this cycle? Would you mind sending me your public ssh key so I can give you access to the buildbots for custom builds and so on?
Cheers,
Julian has done most of the work for 1.8.1. I did the 1.8.0 release because it needed doing, but building releases isn't my strong point and Ralf actually did the builds for that. So I'll happily send you my ssh, but either Ralph or Julian might be a better bet for getting the work done :)
Or, I might add, yourself, if you are interested in taking over that role.
I don't know the code well enough to be the release manager, but I'm very happy to do the OSX binary builds. So - release manager VP of OSX maybe?
That would be helpful. Ralf does those now and I suspect he would welcome the extra hands. The two sites for release builds are Sourceforge and Pypi. I don't know if the wheels builds are good enough/accepted on Pypi, but if you would like permissions on Sourceforge we can extend them to you. We have been trying to do releases for OSX 1.5, which needs a machine running an obsolete OS, but perhaps we should consider dropping that in the future. Chuck
Hi, On Thu, Mar 6, 2014 at 11:21 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Mar 6, 2014 at 12:05 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Thu, Mar 6, 2014 at 9:37 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Mar 6, 2014 at 10:35 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Wed, Mar 5, 2014 at 7:28 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Mar 5, 2014 at 3:29 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I built (and tested) some numpy wheels for the rc1:
Now building, installing, testing, uploading wheels nightly on OSX 10.9:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7 http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3
and downloading, testing built wheels on OSX 10.6:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7-downloaded
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3-downloaded
Chuck - are you release manager for this cycle? Would you mind sending me your public ssh key so I can give you access to the buildbots for custom builds and so on?
Cheers,
Julian has done most of the work for 1.8.1. I did the 1.8.0 release because it needed doing, but building releases isn't my strong point and Ralf actually did the builds for that. So I'll happily send you my ssh, but either Ralph or Julian might be a better bet for getting the work done :)
Or, I might add, yourself, if you are interested in taking over that role.
I don't know the code well enough to be the release manager, but I'm very happy to do the OSX binary builds. So - release manager VP of OSX maybe?
That would be helpful. Ralf does those now and I suspect he would welcome the extra hands. The two sites for release builds are Sourceforge and Pypi. I don't know if the wheels builds are good enough/accepted on Pypi, but if you would like permissions on Sourceforge we can extend them to you. We have been trying to do releases for OSX 1.5, which needs a machine running an obsolete OS, but perhaps we should consider dropping that in the future.
Ralf - any thoughts? pypi is accepting wheels: http://pythonwheels.com/ https://pypi.python.org/pypi/pyzmq/14.0.1 Chris B - any comments here? As for the numpy wheels specifically - I believe the ones I posted are correct - but I would very much like to get feedback. And - yes please for access to the sourceforge site so I can upload the wheels for testing. I'd recommend dropping 10.5 compatibility and going for 10.6. Apple hasn't updated 10.5 since 2009. For example, Firefox dropped support for it in 2012. I do have a couple of machines running 10.5 if you need it though. Cheers, Matthew
On Thu, Mar 6, 2014 at 11:38 AM, Matthew Brett <matthew.brett@gmail.com>wrote:
pypi is accepting wheels:
http://pythonwheels.com/ https://pypi.python.org/pypi/pyzmq/14.0.1
Chris B - any comments here?
It's my understanding that pypi accepts wheels built for the python.orgreleases -- and pip should be able to get the right ones in that case. As far as I know, it's up to the project managers to decide what to put up there. Also, I _think_ that macports, homebrew, and hopefully the Apple builds, won't match to the python.org names, so people won't accidentally get a mis-matched binary wheel.
As for the numpy wheels specifically - I believe the ones I posted are correct - but I would very much like to get feedback.
I, for one will try to test on a couple machines. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Hi, On Thu, Mar 6, 2014 at 12:36 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Thu, Mar 6, 2014 at 11:38 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
pypi is accepting wheels:
http://pythonwheels.com/ https://pypi.python.org/pypi/pyzmq/14.0.1
Chris B - any comments here?
It's my understanding that pypi accepts wheels built for the python.org releases -- and pip should be able to get the right ones in that case.
As far as I know, it's up to the project managers to decide what to put up there.
Also, I _think_ that macports, homebrew, and hopefully the Apple builds, won't match to the python.org names, so people won't accidentally get a mis-matched binary wheel.
I believe that the wheels built against python.org python will in any case work with system python. I've just tested the wheel I built [1] on a 10.7 machine in a system python virtualenv - all tests pass. In any case, unless we do something extra, the built wheel won't install into system python by default, because the wheel name can't match the name system python expects. Here I tested the situation I'd expect when the wheel is on pypi, by downloading the wheel to the current directory of a 10.7 machine and: pip install --pre --find-links . numpy pip doesn't accept the wheel and starts a source install. This is because of the platform tag [2]. System python expects a platform tag that matches the result of `distutils.util.get_platform()`. The python.org builds always have `10_6_intel` for this. On a 10.7 machine: $ /Library/Frameworks/Python.framework/Versions/2.7/bin/python -c "import distutils.util; print(distutils.util.get_platform())" macosx-10.6-intel $ /Library/Frameworks/Python.framework/Versions/3.3/bin/python3 -c "import distutils.util; print(distutils.util.get_platform())" macosx-10.6-intel System python has the actual OSX version. On 10.7 again: $ /usr/bin/python -c "import distutils.util; print(distutils.util.get_platform())" macosx-10.7-intel On 10.9: $ /usr/bin/python -c "import distutils.util; print(distutils.util.get_platform())" macosx-10.9-intel In fact, if I rename my wheel from `numpy-1.8.1rc1-cp27-none-macosx_10_6_intel.whl` to `numpy-1.8.1rc1-cp27-none-macosx_10_6_intel.macosx_10_7_intel.whl`, system python will pick up this wheel, but obviously this could get boring for lots of OSX versions, and in any case, it's not really our target market for the wheels. [4] Min RK actually has a pull request in to relax this OSX version specificity [3] because the wheels should be (and seem to be) interoperable, but the take-home is that we're not likely to run into trouble with system python. Cheers, Matthew [1] http://nipy.bic.berkeley.edu/numpy-dist/numpy-1.8.1rc1-cp27-none-macosx_10_6... [2] http://legacy.python.org/dev/peps/pep-0425/ [3] https://github.com/pypa/pip/pull/1465 [4] http://legacy.python.org/dev/peps/pep-0425/#compressed-tag-sets
On Thu, Mar 6, 2014 at 1:14 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
I believe that the wheels built against python.org python will in any case work with system python.
IIUC, the system python is built agains an up-to-date SDK. so it wouldn't run on an older OS version -- and why would anyone want it to -- it comes with the system. Our wheels are built with the 10.6 SDK -- OS-X is supposed to be backward compatible, so 10.6 SDK code will run on newer OS versions -- but could there be any clashes if a shared lib is linked in that uses a different SDK than the host application? I have no idea if this is expected to be robust -- though the linker doesn't given an error -- so maybe. I've just tested the wheel I built [1] on a 10.7 machine in a system
python virtualenv - all tests pass.
Good start.
In any case, unless we do something extra, the built wheel won't install into system python by default, because the wheel name can't match the name system python expects. Here I tested the situation I'd expect when the wheel is on pypi, by downloading the wheel to the current directory of a 10.7 machine and:
pip install --pre --find-links . numpy
pip doesn't accept the wheel and starts a source install. This is because of the platform tag [2]. System python expects a platform tag that matches the result of `distutils.util.get_platform()`. The python.org builds always have `10_6_intel` for this. On a 10.7 machine:
System python has the actual OSX version. On 10.7 again:
$ /usr/bin/python -c "import distutils.util; print(distutils.util.get_platform())" macosx-10.7-intel
interesting -- the "intel" part of that means is SHOULD be a universal binary with 32 and 64 bit in there. And on my 10.7 system, it is. So maybe this should work. In fact, if I rename my wheel from
`numpy-1.8.1rc1-cp27-none-macosx_10_6_intel.whl` to `numpy-1.8.1rc1-cp27-none-macosx_10_6_intel.macosx_10_7_intel.whl`, system python will pick up this wheel, but obviously this could get boring for lots of OSX versions, and in any case, it's not really our target market for the wheels. [4]
Exactly, though if we can support it easily, maybe good to do. Min RK actually has a pull request in to relax this OSX version
specificity [3] because the wheels should be (and seem to be) interoperable, but the take-home is that we're not likely to run into trouble with system python.
If we relax things too much, will we also get homebrew and macports and built-it-myself pythons, and will they work? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Thu, Mar 6, 2014 at 11:10 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Thu, Mar 6, 2014 at 1:14 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
I believe that the wheels built against python.org python will in any case work with system python.
IIUC, the system python is built agains an up-to-date SDK. so it wouldn't run on an older OS version -- and why would anyone want it to -- it comes with the system.
Our wheels are built with the 10.6 SDK -- OS-X is supposed to be backward compatible, so 10.6 SDK code will run on newer OS versions -- but could there be any clashes if a shared lib is linked in that uses a different SDK than the host application? I have no idea if this is expected to be robust -- though the linker doesn't given an error -- so maybe.
I just commented on this issue on the pip PR - our dmg installers are built *on 10.6*, not with the 10.6 SDK. Those two are not equivalent, and the last time I tried using an SDK we had users reporting crashes with the binaries on SF.
interesting -- the "intel" part of that means is SHOULD be a universal binary with 32 and 64 bit in there. And on my 10.7 system, it is. So maybe this should work.
In fact, if I rename my wheel from
`numpy-1.8.1rc1-cp27-none-macosx_10_6_intel.whl` to `numpy-1.8.1rc1-cp27-none-macosx_10_6_intel.macosx_10_7_intel.whl`, system python will pick up this wheel, but obviously this could get boring for lots of OSX versions, and in any case, it's not really our target market for the wheels. [4]
Exactly, though if we can support it easily, maybe good to do.
Min RK actually has a pull request in to relax this OSX version
specificity [3] because the wheels should be (and seem to be) interoperable, but the take-home is that we're not likely to run into trouble with system python.
If we relax things too much, will we also get homebrew and macports and built-it-myself pythons, and will they work?
Not likely. On 10.7 and 10.8 python.org and system python use llvm-gcc while IIRC homebrew used clang. There's probably more differences. Ralf
Hi, Thanks to Chuck and Jarrod for giving me upload permission - wheels are on sourceforge now: https://sourceforge.net/projects/numpy/files/NumPy/1.8.1rc1 Until the wheels reach pypi, you'll have to test by: * downloading the python 2.7 or 3.3 wheel to a directory (say the current directory) and: * upgrading pip to latest (1.5.4): http://pip.readthedocs.org/en/latest/installing.html * pip install --pre --find-links . numpy The wheels match the python.org python. You can make them install on system python at your own risk (likely small) with `pip install numpy-1.8.1rc1-cp27-none-macosx_10_6_intel.whl` (hoping you do in fact have python 2.7 as your system python). Feedback very welcome, especially from anyone running homebrew python trying the direct pip install above. Cheers, Matthew
On Sat, Mar 8, 2014 at 10:06 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
Thanks to Chuck and Jarrod for giving me upload permission - wheels are on sourceforge now:
Nice!
Until the wheels reach pypi, you'll have to test by:
If you send me your pypi username I'll give you the right permissions there also. Ralf
* downloading the python 2.7 or 3.3 wheel to a directory (say the current directory) and: * upgrading pip to latest (1.5.4): http://pip.readthedocs.org/en/latest/installing.html * pip install --pre --find-links . numpy
The wheels match the python.org python. You can make them install on system python at your own risk (likely small) with `pip install numpy-1.8.1rc1-cp27-none-macosx_10_6_intel.whl` (hoping you do in fact have python 2.7 as your system python).
Feedback very welcome, especially from anyone running homebrew python trying the direct pip install above.
Cheers,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, On Mon, Mar 10, 2014 at 11:09 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Mar 8, 2014 at 10:06 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
Thanks to Chuck and Jarrod for giving me upload permission - wheels are on sourceforge now:
Nice!
Until the wheels reach pypi, you'll have to test by:
If you send me your pypi username I'll give you the right permissions there also.
Thanks - that would be great - 'matthew.brett' on pypi. Cheers, Matthew
On Tue, Mar 11, 2014 at 9:26 AM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Mon, Mar 10, 2014 at 11:09 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Mar 8, 2014 at 10:06 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
Thanks to Chuck and Jarrod for giving me upload permission - wheels are on sourceforge now:
Nice!
Until the wheels reach pypi, you'll have to test by:
If you send me your pypi username I'll give you the right permissions
there
also.
Thanks - that would be great - 'matthew.brett' on pypi.
You're a numpy admin now. Thanks for picking this up, will be quite useful in the long run! Cheers, Ralf
On Sat, Mar 8, 2014 at 2:22 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
If we relax things too much, will we also get homebrew and macports and built-it-myself pythons, and will they work?
Not likely. On 10.7 and 10.8 python.org and system python use llvm-gcc while IIRC homebrew used clang. There's probably more differences.
So the question is: If someone is running a brew python and does "pip install numpy" will pip find a binary wheel that will then not work? That would be bad, but maybe not our problem -- brew users should be using brew to build numpy anyway. It would be nicer if it didn't happen, though. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Mon, Mar 10, 2014 at 4:39 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Sat, Mar 8, 2014 at 2:22 AM, Ralf Gommers <ralf.gommers@gmail.com>wrote:
If we relax things too much, will we also get homebrew and macports and built-it-myself pythons, and will they work?
Not likely. On 10.7 and 10.8 python.org and system python use llvm-gcc while IIRC homebrew used clang. There's probably more differences.
So the question is:
If someone is running a brew python and does "pip install numpy" will pip find a binary wheel that will then not work? That would be bad, but maybe not our problem -- brew users should be using brew to build numpy anyway.
No that is not how homebrew works. Brew does not pack anything that pip installable: https://github.com/Homebrew/homebrew/wiki/Homebrew-and-Python so that would be a big issue. Especially since installing numpy with pip and brew python just works without any problem when building from source. There are unofficial brew taps (channels) with python packages but this not the recommended way. /Jens
It would be nicer if it didn't happen, though.
-CHB
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Mar 10, 2014 at 6:27 PM, Jens Nielsen <jenshnielsen@gmail.com>wrote:
On Mon, Mar 10, 2014 at 4:39 PM, Chris Barker <chris.barker@noaa.gov>wrote:
On Sat, Mar 8, 2014 at 2:22 AM, Ralf Gommers <ralf.gommers@gmail.com>wrote:
If we relax things too much, will we also get homebrew and macports and built-it-myself pythons, and will they work?
Not likely. On 10.7 and 10.8 python.org and system python use llvm-gcc while IIRC homebrew used clang. There's probably more differences.
So the question is:
If someone is running a brew python and does "pip install numpy" will pip find a binary wheel that will then not work? That would be bad, but maybe not our problem -- brew users should be using brew to build numpy anyway.
"pip install numpy" will build from source, and if "pip install numpy --use-wheel" doesn't work I guess we should fix it by documentation that in all the obvious places. Ralf
No that is not how homebrew works. Brew does not pack anything that pip installable: https://github.com/Homebrew/homebrew/wiki/Homebrew-and-Python so that would be a big issue. Especially since installing numpy with pip and brew python just works without any problem when building from source.
There are unofficial brew taps (channels) with python packages but this not the recommended way.
/Jens
It would be nicer if it didn't happen, though.
-CHB
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
_______________________________________________ NumPy-Discussion mailing list 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, Mar 10, 2014 at 10:27 AM, Jens Nielsen <jenshnielsen@gmail.com>wrote:
If someone is running a brew python and does "pip install numpy" will pip find a binary wheel that will then not work? That would be bad, but maybe not our problem -- brew users should be using brew to build numpy anyway.
No that is not how homebrew works. Brew does not pack anything that pip installable: https://github.com/Homebrew/homebrew/wiki/Homebrew-and-Python so that would be a big issue. Especially since installing numpy with pip and brew python just works without any problem when building from source.
There are unofficial brew taps (channels) with python packages but this not the recommended way.
OK, then I'll re-phrase: Brew users should be building from source anyway, even if they use pip to do it. But it would be bad if they had to go out of their way to do that -- I've lost track of pip's default behavior in this regard. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Hi, On Mon, Mar 10, 2014 at 12:37 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Mon, Mar 10, 2014 at 10:27 AM, Jens Nielsen <jenshnielsen@gmail.com> wrote:
If someone is running a brew python and does "pip install numpy" will pip find a binary wheel that will then not work? That would be bad, but maybe not our problem -- brew users should be using brew to build numpy anyway.
No that is not how homebrew works. Brew does not pack anything that pip installable: https://github.com/Homebrew/homebrew/wiki/Homebrew-and-Python so that would be a big issue. Especially since installing numpy with pip and brew python just works without any problem when building from source.
There are unofficial brew taps (channels) with python packages but this not the recommended way.
OK, then I'll re-phrase:
Brew users should be building from source anyway, even if they use pip to do it.
But it would be bad if they had to go out of their way to do that -- I've lost track of pip's default behavior in this regard.
We should be fine for homebrew. I believe: 1) The wheels work for homebrew as well 2) Homebrew won't pick them up by default at the moment Homebrew python has a more specific architecture version then the python.org python or system python: $ /usr/local/Cellar/python/2.7.6/bin/python -c "import distutils.util; print(distutils.util.get_platform())" macosx-10.9-x86_64 So - for now - pip won't recognize the 10.6_intel wheel as matching the required 10.9_x86_64 suffix on the wheel (can be solved by renaming the file as further up the thread). But - in any case - the wheels work fine in homebrew: mkvirtualenv homebrew-2.7 --python=/usr/local/Cellar/python/2.7.6/bin/python pip install nose # this doesn't see the wheel - because of the platform tag # starts to download and install from source pip install --pre --find-links . numpy # this works pip install numpy-1.8.1rc1-cp27-none-macosx_10_6_intel.whl # tests all pass python -c 'import numpy; numpy.test()' # We're picking up the right numpy python -c 'import numpy; print(numpy.__file__)' deactivate # same for 3.3 mkvirtualenv homebrew-3.3 --python=/usr/local/Cellar/python3/3.3.5/bin/python3 pip install nose python -c 'import numpy' pip install --pre --find-links . numpy pip install numpy-1.8.1rc1-cp33-cp33m-macosx_10_6_intel.whl python -c 'import numpy; numpy.test()' So I think we're good. We should surely set up automated testing to assure ourselves that this is still true, when there's time, it shouldn't take very long. Cheers, Matthew
On Thu, Mar 6, 2014 at 8:38 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Thu, Mar 6, 2014 at 11:21 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Mar 6, 2014 at 12:05 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Thu, Mar 6, 2014 at 9:37 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Julian has done most of the work for 1.8.1. I did the 1.8.0 release because it needed doing, but building releases isn't my strong point and Ralf actually did the builds for that. So I'll happily send you my ssh, but either Ralph or Julian might be a better bet for getting the work done :)
Or, I might add, yourself, if you are interested in taking over that role.
I don't know the code well enough to be the release manager, but I'm very happy to do the OSX binary builds. So - release manager VP of OSX maybe?
That would be helpful. Ralf does those now and I suspect he would welcome the extra hands.
He would:)
The two sites for release builds are Sourceforge and Pypi.
I don't know if the wheels builds are good enough/accepted on Pypi, but if you would like permissions on Sourceforge we can extend them to you. We have been trying to do releases for OSX 1.5, which needs a machine running an obsolete OS, but perhaps we should consider dropping that in the future.
Ralf - any thoughts?
pypi is accepting wheels:
http://pythonwheels.com/ https://pypi.python.org/pypi/pyzmq/14.0.1
We tried once to put wheels on SF without much response, and if we put them on testpypi I don't expect much more. Since the wheels appear to work, let's just put them on PyPi and fix possible issues if and when they show up. Ralf
On Thu, Mar 6, 2014 at 11:21 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
That would be helpful. Ralf does those now and I suspect he would welcome the extra hands. The two sites for release builds are Sourceforge and Pypi. I don't know if the wheels builds are good enough/accepted on Pypi,
Would anyone decide that other than this group?
but if you would like permissions on Sourceforge we can extend them to you. We have been trying to do releases for OSX 1.5, which needs a machine running an obsolete OS, but perhaps we should consider dropping that in the future.
Drop that baby! First, it's bit odd -- as I undertand it, the python.org builds support either 10.3.9 + or 10.6+. As 10.5 has not been supported for Apple for a couple years, and 10.6 is getting pretty darn long in the tooth, the only reason to support that older build is for PPC support - I wonder how many folks are still running PPCs? I thought I was one of the hold outs, and I dropped it over a year ago. I'd love to know if it is something that the community still needs to support. And thanks for doing this Matthew! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Thu, Mar 6, 2014 at 1:32 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Thu, Mar 6, 2014 at 11:21 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
That would be helpful. Ralf does those now and I suspect he would welcome the extra hands. The two sites for release builds are Sourceforge and Pypi. I don't know if the wheels builds are good enough/accepted on Pypi,
Would anyone decide that other than this group?
but if you would like permissions on Sourceforge we can extend them to you. We have been trying to do releases for OSX 1.5, which needs a machine running an obsolete OS, but perhaps we should consider dropping that in the future.
Drop that baby!
First, it's bit odd -- as I undertand it, the python.org builds support either 10.3.9 + or 10.6+. As 10.5 has not been supported for Apple for a couple years, and 10.6 is getting pretty darn long in the tooth, the only reason to support that older build is for PPC support - I wonder how many folks are still running PPCs? I thought I was one of the hold outs, and I dropped it over a year ago. I'd love to know if it is something that the community still needs to support.
Now that I look on sourceforge, I don't see any OS X 10.5 builds, they are all 10.6+. So that bit of support seems to have dropped in reality, if not officially. Chuck
On Thu, Mar 6, 2014 at 2:10 PM, Charles R Harris <charlesr.harris@gmail.com>wrote:
On Thu, Mar 6, 2014 at 1:32 PM, Chris Barker <chris.barker@noaa.gov>wrote:
On Thu, Mar 6, 2014 at 11:21 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
That would be helpful. Ralf does those now and I suspect he would welcome the extra hands. The two sites for release builds are Sourceforge and Pypi. I don't know if the wheels builds are good enough/accepted on Pypi,
Would anyone decide that other than this group?
but if you would like permissions on Sourceforge we can extend them to you. We have been trying to do releases for OSX 1.5, which needs a machine running an obsolete OS, but perhaps we should consider dropping that in the future.
Drop that baby!
First, it's bit odd -- as I undertand it, the python.org builds support either 10.3.9 + or 10.6+. As 10.5 has not been supported for Apple for a couple years, and 10.6 is getting pretty darn long in the tooth, the only reason to support that older build is for PPC support - I wonder how many folks are still running PPCs? I thought I was one of the hold outs, and I dropped it over a year ago. I'd love to know if it is something that the community still needs to support.
Now that I look on sourceforge, I don't see any OS X 10.5 builds, they are all 10.6+. So that bit of support seems to have dropped in reality, if not officially.
The last release to support earlier than that was 1.7.1, which supported 10.3 and that has 643 downloads total. Chuck
On Thu, Mar 6, 2014 at 10:10 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Thu, Mar 6, 2014 at 1:32 PM, Chris Barker <chris.barker@noaa.gov>wrote:
On Thu, Mar 6, 2014 at 11:21 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
That would be helpful. Ralf does those now and I suspect he would welcome the extra hands. The two sites for release builds are Sourceforge and Pypi. I don't know if the wheels builds are good enough/accepted on Pypi,
Would anyone decide that other than this group?
No, that's up to us.
but if you would like permissions on Sourceforge we can extend them to you. We have been trying to do releases for OSX 1.5, which needs a machine running an obsolete OS, but perhaps we should consider dropping that in the future.
Drop that baby!
+1
First, it's bit odd -- as I undertand it, the python.org builds support either 10.3.9 + or 10.6+. As 10.5 has not been supported for Apple for a couple years, and 10.6 is getting pretty darn long in the tooth, the only reason to support that older build is for PPC support - I wonder how many folks are still running PPCs? I thought I was one of the hold outs, and I dropped it over a year ago. I'd love to know if it is something that the community still needs to support.
Now that I look on sourceforge, I don't see any OS X 10.5 builds, they are all 10.6+. So that bit of support seems to have dropped in reality, if not officially.
For RCs I usually don't bother, because the setup is a bit awkward (the 10.5 machine sits in Vincent's basement and he needs to start up for me) and there are too few testers for those to get useful feedback anyway. For 1.8.0 I planned to get back to that after uploading the 10.6 ones, but forgot. Because no one noticed until now, it looks like spending effort on 10.5 support isn't all that useful. Ralf
On 06.03.2014 20:05, Matthew Brett wrote:
Hi, On Thu, Mar 6, 2014 at 9:37 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Mar 6, 2014 at 10:35 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Wed, Mar 5, 2014 at 7:28 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Mar 5, 2014 at 3:29 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I built (and tested) some numpy wheels for the rc1:
Now building, installing, testing, uploading wheels nightly on OSX 10.9:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7 http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3
and downloading, testing built wheels on OSX 10.6:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7-downloaded http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3-downloaded
Chuck - are you release manager for this cycle? Would you mind sending me your public ssh key so I can give you access to the buildbots for custom builds and so on?
Cheers,
Julian has done most of the work for 1.8.1. I did the 1.8.0 release because it needed doing, but building releases isn't my strong point and Ralf actually did the builds for that. So I'll happily send you my ssh, but either Ralph or Julian might be a better bet for getting the work done :)
Or, I might add, yourself, if you are interested in taking over that role.
I don't know the code well enough to be the release manager, but I'm very happy to do the OSX binary builds. So - release manager VP of OSX maybe?
Cheers,
Matthew
I'm using Ondřej Čertík nice vagrant setup to do the releases, maybe you can have a look if the macos stuff still works with it and updated it for your wheels? https://github.com/juliantaylor/numpy-vendor
Hi, On Thu, Mar 6, 2014 at 11:24 AM, Julian Taylor <jtaylor.debian@googlemail.com> wrote:
On 06.03.2014 20:05, Matthew Brett wrote:
Hi, On Thu, Mar 6, 2014 at 9:37 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Mar 6, 2014 at 10:35 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Wed, Mar 5, 2014 at 7:28 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Mar 5, 2014 at 3:29 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I built (and tested) some numpy wheels for the rc1:
Now building, installing, testing, uploading wheels nightly on OSX 10.9:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7 http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3
and downloading, testing built wheels on OSX 10.6:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7-downloaded http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3-downloaded
Chuck - are you release manager for this cycle? Would you mind sending me your public ssh key so I can give you access to the buildbots for custom builds and so on?
Cheers,
Julian has done most of the work for 1.8.1. I did the 1.8.0 release because it needed doing, but building releases isn't my strong point and Ralf actually did the builds for that. So I'll happily send you my ssh, but either Ralph or Julian might be a better bet for getting the work done :)
Or, I might add, yourself, if you are interested in taking over that role.
I don't know the code well enough to be the release manager, but I'm very happy to do the OSX binary builds. So - release manager VP of OSX maybe?
Cheers,
Matthew
I'm using Ondřej Čertík nice vagrant setup to do the releases, maybe you can have a look if the macos stuff still works with it and updated it for your wheels? https://github.com/juliantaylor/numpy-vendor
Thanks - looking at it now. Is there already a dedicated "Mac build box" somewhere ? If not, I can set one up. Cheers, Matthew
On Thu, Mar 6, 2014 at 12:43 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Thu, Mar 6, 2014 at 11:24 AM, Julian Taylor <jtaylor.debian@googlemail.com> wrote:
On 06.03.2014 20:05, Matthew Brett wrote:
Hi, On Thu, Mar 6, 2014 at 9:37 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Mar 6, 2014 at 10:35 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Wed, Mar 5, 2014 at 7:28 PM, Matthew Brett < matthew.brett@gmail.com> wrote:
Hi,
On Wed, Mar 5, 2014 at 3:29 PM, Matthew Brett < matthew.brett@gmail.com> wrote: > Hi, > > I built (and tested) some numpy wheels for the rc1: > > http://nipy.bic.berkeley.edu/numpy-dist/
Now building, installing, testing, uploading wheels nightly on OSX 10.9:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7 http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3
and downloading, testing built wheels on OSX 10.6:
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7-downloaded
http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3-downloaded
Chuck - are you release manager for this cycle? Would you mind sending me your public ssh key so I can give you access to the buildbots for custom builds and so on?
Cheers,
Julian has done most of the work for 1.8.1. I did the 1.8.0 release because it needed doing, but building releases isn't my strong point and Ralf actually did the builds for that. So I'll happily send you my ssh, but either Ralph or Julian might be a better bet for getting the work done :)
Or, I might add, yourself, if you are interested in taking over that role.
I don't know the code well enough to be the release manager, but I'm very happy to do the OSX binary builds. So - release manager VP of OSX maybe?
Cheers,
Matthew
I'm using Ondřej Čertík nice vagrant setup to do the releases, maybe you can have a look if the macos stuff still works with it and updated it for your wheels? https://github.com/juliantaylor/numpy-vendor
Thanks - looking at it now. Is there already a dedicated "Mac build box" somewhere ? If not, I can set one up.
What is your sourceforge identity? If you don't have one, please register. Chuck
thanks for the report, thix should be fixed with https://github.com/numpy/numpy/pull/4455 which will be in the final 1.8.1 On 04.03.2014 13:49, Thomas Unterthiner wrote:
Hi there!
I just tried setting up a new installation using numpy 1.8.1rc1 (+scipy 0.13.3 and matplotlib 1.3.1). I ran into problems when installing matplotlib 1.3.1. The attached logfile shows the full log, but it ends with:
src/_png.cpp:329:15: error: ‘npy_PyFile_Dup’ was not declared in this scope if ((fp = npy_PyFile_Dup(py_file, "rb"))) ^ src/_png.cpp:577:13: error: ‘npy_PyFile_DupClose’ was not declared in this scope if (npy_PyFile_DupClose(py_file, fp)) { ^ error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
The problem went away (and matplotlib installed cleanly) when I re-did the whole shebang using numpy 1.8.0, so I suspect this was caused by something in the rc.
Cheers
Thomas
On 2014-03-03 17:23, Charles R Harris wrote:
Hi All,
Julian Taylor has put windows binaries and sources for the 1.8.1 release candidate up on sourceforge <http://sourceforge.net/projects/numpy/files/NumPy/1.8.1rc1/>. If things go well, it will taken to a full release in a week or so.
Chuck
_______________________________________________ NumPy-Discussion mailing list 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
participants (9)
-
Charles R Harris -
Chris Barker -
Christoph Gohlke -
Jens Nielsen -
Julian Taylor -
Matthew Brett -
Ralf Gommers -
Sebastian Berg -
Thomas Unterthiner