Hi, On Mon, Feb 24, 2014 at 12:40 PM, Matthew Brett <matthew.brett@gmail.com> wrote:

Hi,

On Sun, Feb 23, 2014 at 10:26 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:

...

Hi All,

A lot of fixes have gone into the 1.8.x branch and it looks about time to do a bugfix release. There are a couple of important bugfixes still to backport, but if all goes well next weekend, March 1, looks like a good target date. So give the current 1.8.x branch a try so as to check that it covers your most urgent bugfix needs.

I'd like to volunteer to make a .whl build for Mac. Is there anything special I should do to coordinate with y'all? It would be very good to put it up on pypi for seamless pip install...

Current trunk wheel at http://nipy.bic.berkeley.edu/scipy_installers/numpy-1.8.0.dev_a89a36e-cp27-n... Testing welcome. You'll need OSX and latest setuptools and latest pip and : curl -O http://nipy.bic.berkeley.edu/scipy_installers/numpy-1.8.0.dev_a89a36e-cp27-n... pip install --pre --no-index --find-links . numpy I built the wheel on a 10.9 laptop and tested it on a bare-metal no-compiler 10.6 laptop, so I think it will work. I'll set up daily wheel build / tests on our buildbots as well. Cheers, Matthew

I build wheels for 32bit and 64bit (Windows, OpenBLAS) and put them here: https://drive.google.com/folderview?id=0B4DmELLTwYmlX05WSWpYVWJfRjg&usp=sharing Due to shortage of time I give not much more detailed informations before 1st of March. Carl 2014-02-25 1:53 GMT+01:00 Chris Barker <chris.barker@noaa.gov>:

What's up with the OpenBLAS work?

Any chance that might make it into official binaries? Or is is just too fresh?

Also -- from an off-hand comment in the thread is looked like OpenBLAS could provide a library that selects for optimized code at run-time depending on hardware -- this would solve the "superpack" problem with wheels, which would be really nice...

Or did I dream that?

-Chris

On Mon, Feb 24, 2014 at 12:40 PM, Matthew Brett <matthew.brett@gmail.com>wrote:

...

Hi,

On Sun, Feb 23, 2014 at 10:26 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:

...

Hi All,

A lot of fixes have gone into the 1.8.x branch and it looks about time to do a bugfix release. There are a couple of important bugfixes still to backport, but if all goes well next weekend, March 1, looks like a good target date. So give the current 1.8.x branch a try so as to check that it covers your most urgent bugfix needs.

I'd like to volunteer to make a .whl build for Mac. Is there anything special I should do to coordinate with y'all? It would be very good to put it up on pypi for seamless pip install...

Thanks a lot,

Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

--

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

Hi, Arnaud finished that in a different way then we had discussed in the PR. https://github.com/numpy/numpy/pull/4081 Fred On Wed, Feb 26, 2014 at 10:07 AM, Frédéric Bastien <nouiz@nouiz.org> wrote:

Hi,

I have a PR that fix way too much printing to stdout when finding the blas linking information:

https://github.com/numpy/numpy/pull/4081

This was created by change in NumPy. I was requested as a comment to put the removed information in the dict that we return to the user. I won't have the time to do this for the 1.8.1rc as I'm in vacation next week and I need to prepar that.

I'll try to find someone else to finish this, but it is not sure. I'll keep you updated on this.

thanks

Frédéric

On Tue, Feb 25, 2014 at 5:52 PM, Carl Kleffner <cmkleffner@gmail.com> wrote:

...

I build wheels for 32bit and 64bit (Windows, OpenBLAS) and put them here: https://drive.google.com/folderview?id=0B4DmELLTwYmlX05WSWpYVWJfRjg&usp=sharing Due to shortage of time I give not much more detailed informations before 1st of March.

Carl

2014-02-25 1:53 GMT+01:00 Chris Barker <chris.barker@noaa.gov>:

...

What's up with the OpenBLAS work?

Any chance that might make it into official binaries? Or is is just too fresh?

Also -- from an off-hand comment in the thread is looked like OpenBLAS could provide a library that selects for optimized code at run-time depending on hardware -- this would solve the "superpack" problem with wheels, which would be really nice...

Or did I dream that?

-Chris

On Mon, Feb 24, 2014 at 12:40 PM, Matthew Brett <matthew.brett@gmail.com> wrote:

...

Hi,

On Sun, Feb 23, 2014 at 10:26 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:

...

Hi All,

A lot of fixes have gone into the 1.8.x branch and it looks about time to do a bugfix release. There are a couple of important bugfixes still to backport, but if all goes well next weekend, March 1, looks like a good target date. So give the current 1.8.x branch a try so as to check that it covers your most urgent bugfix needs.

I'd like to volunteer to make a .whl build for Mac. Is there anything special I should do to coordinate with y'all? It would be very good to put it up on pypi for seamless pip install...

Thanks a lot,

Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

--

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 Wed, Feb 26, 2014 at 8:27 AM, Tom Augspurger <tom.augspurger88@gmail.com>wrote:

Thanks for posting those wheels Matthew.

I'm on a Mac (10.9.2) and I had trouble installing numpy from your wheel in a fresh virtualenv with the latests pip, setuptools, and wheel.

``` $pip install ~/Downloads/numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_9_intel.whl numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_9_intel.whl is not a supported wheel on this platform. Storing debug log for failure in /Users/admin/.pip/pip.log ```

IIRC, those wheels are built for the pyton.org builds of python: macosx_10_9 means it was built on 10.9 (though that should be 10.6, I think, as it is built FOR 106+, not only 10.9..) _intel means it's an Intel build, which in the nomenclature used in the pyton.org builds, means it's a universal 32 and 64 bit Intel

When I build a wheel from source, my platform is `x86_64`.

What python are you using? apparently not a Universal 32+64 bit build. The one Apple delivers? ```

$mv numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_6_intel.whl numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_6_x86_64.whl ```

and then running `pip install` on that wheel successfully installed numpy (and the test suite passed).

I'm not entirely sure we can count on that working, as I _think_ the SDK that the wheel was built against is different than the one your python was built against. But it theory, one should be able to install a universal wheel into a one-of-the-architectures build, the other one will get ignored (as it seems to be for you), but I think it's fragile in general. This is a serious issue with binary wheels -- there are so many variations to a "platform" -- the naming scheme covers OS, OS version, and bit depth, but not system library versions, and who the heck knows what else. This has been discussed a lot on the dist_utils list, with no real solution in sight: - there are other alternative, for instance, I think conda packages have some sort of hash or something to make sure that binary packages all match. - convention is the other option: - use binary wheel for in-house deplyment to similar systems - use binary wheels for a well-defined python build: - for PyPi, that's the python.org builds for Windows and OS- -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 Wed, Feb 26, 2014 at 11:34 AM, Matthew Brett <matthew.brett@gmail.com>wrote:

...

- convention is the other option: - use binary wheel for in-house deplyment to similar systems - use binary wheels for a well-defined python build: - for PyPi, that's the python.org builds for Windows and OS-

Thanks - that is a very useful summary.

It would make sense I think to provide numpy wheels like mine via pypi - as pyzmq does for example.

Indeed -- and I really appreciate your efforts on this -- I think we should be able to get the whole "stack" up there pretty soon (though there is an issue with iPython and readline...) Ralf had put together a test set of these, too a little while ago.

In this case, I believe (Chris correct me if I'm wrong) that someone running via system python would get the usual compile / install, but someone running python.org python would get a near instant numpy,

That's the idea -- though not entirely sure how that would go without testing. Also, I think with pip, you need to tell it to look for binary wheels -- it won't do that by default. pip install --use-wheel numpy so that seems like a clear win.

Agreed. The trick is that it's reasonable for users of Apple's python build to want this too -- but I don't know how we can hope to provide that. (and macports, and homebrew... but those I feel better about requiring to build your own -- really, that's what those systems are designed to do) -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 Wed, Feb 26, 2014 at 2:48 PM, Matthew Brett <matthew.brett@gmail.com>wrote:

...

Agreed. The trick is that it's reasonable for users of Apple's python build to want this too -- but I don't know how we can hope to provide that.

We don't support system python for the mpkg, so I think it's reasonable to leave this little gift for our fellow python.org friends.

I agree. We decided long ago on the pythonmac list that supporting Apple's python builds was a dead-end.

In that case, the OSX instructions could (within the next few months) be as simple as:

Install python from binary installer at python.org curl -O https://raw.github.com/pypa/pip/master/contrib/get-pip.py python get-pip.py pip install scipy-stack

or similar.

yup -- that'st he goal, and think we really are close. Does pip and PyPi "officially" support meta-packages like that? i.e. I take it that scipy-stack would be a package that had nothing except dependencies. I do like the idea. Getting a bit OT for the numpy list, but... As I understand it, there was a stumbling block with wheels for the SciPy stack around iPython and readline -- some systems require th readline package, some don't. As I write this, I can't remember why it would be the lest bit hard to simply require readline in teh Mac Wheels, but there was some debate on the iPython list, and it seemed not-so-easy to resolve... -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, Should [1] be considered a release blocker for 1.8.1? Skipper [1] https://github.com/numpy/numpy/issues/4442

Thanks Chris, Chris Barker - NOAA Federal wrote

What python are you using? apparently not a Universal 32+64 bit build. The one Apple delivers?

I'm using homebrew python, so the platform difference seems to have come from there. I agree about renaming the file as not being a real solution. I'd say the official python.org python is the one to worry about for PyPI (which is what pyzmq seems to do). -Tom -- View this message in context: http://numpy-discussion.10968.n7.nabble.com/1-8-1-release-tp36603p36662.html Sent from the Numpy-discussion mailing list archive at Nabble.com.

On Wed, Feb 26, 2014 at 3:10 PM, Tom Augspurger <tom.augspurger88@gmail.com>wrote:

Chris Barker - NOAA Federal wrote

...

What python are you using? apparently not a Universal 32+64 bit build. The one Apple delivers?

I'm using homebrew python, so the platform difference seems to have come from there.

and it _should_ -- in theory, and often in practice, you should be able to get packages for hamebrew with either: brew install the_package_name or pip install the_package_name and let it compile away. But we wouldn't want a brew python to find a binary wheel built for the python.org python -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