An idea for future numpy windows installers
Hi, While studying a bit nsis (an open source system to build windows installers), I realized that it would be good if we could detect the target CPU and install the right numpy accordingly. I have coded a nsis plugin to detect SSE availability (no SSE vs SSE vs SSE2 vs SS3), and including installers within the nsis installer is easy. What would people think about including the installers generated with the current method (bdist_wininst, I guess ?) for every CPU target, and distribute the bundled installer ? The only drawback I can see is the size of the installer: in this case, we could have a system which download the right installer, but that would be more work, obviously. This seems like an easy, "not too much work required" solution to the recurrent problem we get with atlas on windows. cheers, David
On Feb 4, 2008 5:13 AM, David Cournapeau <cournape@gmail.com> wrote:
Hi,
While studying a bit nsis (an open source system to build windows installers), I realized that it would be good if we could detect the target CPU and install the right numpy accordingly. I have coded a nsis plugin to detect SSE availability (no SSE vs SSE vs SSE2 vs SS3), and including installers within the nsis installer is easy. What would people think about including the installers generated with the current method (bdist_wininst, I guess ?) for every CPU target, and distribute the bundled installer ? The only drawback I can see is the size of the installer: in this case, we could have a system which download the right installer, but that would be more work, obviously. This seems like an easy, "not too much work required" solution to the recurrent problem we get with atlas on windows.
I like the idea of creating such a "universal" Windows installer for the (optional) numpy dependencies (particularly ATLAS) which is separate from the numpy distribution. Ultimately, it would be great if numpy automatically noticed if ATLAS has been installed this way and self-configured itself to use the libraries when available, but I would still consider this a better situation if it was easy to build numpy to use such an installation with numscons. This would also provide a natural decoupling between the numpy and ATLAS distributions.
On Feb 4, 2008 5:13 AM, David Cournapeau <cournape@gmail.com> wrote:
Hi,
While studying a bit nsis (an open source system to build windows installers), I realized that it would be good if we could detect the target CPU and install the right numpy accordingly. I have coded a nsis plugin to detect SSE availability (no SSE vs SSE vs SSE2 vs SS3), and including installers within the nsis installer is easy. What would people think about including the installers generated with the current method (bdist_wininst, I guess ?) for every CPU target, and distribute the bundled installer ? The only drawback I can see is the size of the installer: in this case, we could have a system which download the right installer, but that would be more work, obviously. This seems like an easy, "not too much work required" solution to the recurrent problem we get with atlas on windows.
I like the idea of creating such a "universal" Windows installer for the (optional) numpy dependencies (particularly ATLAS) which is separate from the numpy distribution. Ultimately, it would be great if numpy automatically noticed if ATLAS has been installed this way and self-configured itself to use the libraries when available, but I would still consider this a better situation if it was easy to build numpy to use such an installation with numscons. Well, this has nothing to do with numscons per se. I indeed started working on this because of my work on numscons, though (I still need to support windows platform, which I find extremely frustrating to work with, and a super pack installer for all numpy/scipy dependencies makes
Alexander Michael wrote: the pain lower for reproducible builds). I see two cases, which is why I suggested this as a separate issue of my recently announced blas/lapack superpack: - people who just want to install numpy: people want to try numpy, they don't want to care about sse and co. That's why an installer with several numpy versions inside would be good: it would work for everybody. - people who work with SVN: particularly for scipy, that's something many people want to. Building blas, lapack and atlas is hard. I think I know the problems pretty well, having build and installed them on so many compiler/platforms combinations by now, but that's not something terribly interesting. And it is hard to explain it well, because it is so easy to make a mistake at some point. So instead of explaining how to do it, just put something which works out of the box: that's what the BLAS/LAPACK superpack is for. cheers, David
participants (3)
-
Alexander Michael -
David Cournapeau -
David Cournapeau