<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 18, 2015 at 9:12 AM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
I'm wondering what people think of the idea of us (= numpy) stopping<br>
providing our "official" win32 builds (the "superpack installers"<br>
distributed on sourceforge) starting with the next release.<br>
<br>
These builds are:<br>
<br>
- low quality: they're linked to an old & untuned build of ATLAS, so<br>
linear algebra will be dramatically slower than builds using MKL or<br>
OpenBLAS. They're win32 only and will never support win64. They're<br>
using an ancient version of gcc. They will never support python 3.5 or<br>
later.<br>
<br>
- a dead end: there's a lot of work going on to solve the windows<br>
build problem, and hopefully we'll have something better in the<br>
short-to-medium-term future; but, any solution will involve throwing<br>
out the current system entirely and switching to a new toolchain,<br>
wheel-based distribution, etc.<br>
<br>
- a drain on our resources: producing these builds is time-consuming<br>
and finicky; I'm told that these builds alone are responsible for a<br>
large proportion of the energy spent preparing each release, and take<br>
away from other things that our release managers could be doing (e.g.<br>
QA and backporting fixes).<br>
<br>
So the idea would be that for 1.11, we create a 1.11 directory on<br>
sourceforge and upload one final file: a README explaining the<br>
situation, a pointer to the source releases on pypi, and some links to<br>
places where users can find better-supported windows builds (Gohlke's<br>
page, Anaconda, etc.). I think this would serve our users better than<br>
the current system, while also freeing up a drain on our resources.<br>
<br>
Thoughts?<br>
<span class=""><font color="#888888"><br>
-n<br></font></span></blockquote><div><br></div></div><br>Hi Nathaniel,<br><br>Speaking as a downstream library (Biopython) using the NumPy<br>C API, we have to ensure binary compatibility with your releases.<br><br>We've continued to produce our own Windows 32 bit installers -<br>originally the .exe kind (from python setup.py bdist_wininst) but<br>now also .msi (from python setup.py bdist_msi).<br><br></div><div class="gmail_extra">However, in the absence of an official 64bit Windows NumPy<br>installer we've simply pointed people at Chris Gohlke's stack<br></div><div class="gmail_extra"><a href="http://www.lfd.uci.edu/~gohlke/pythonlibs/">http://www.lfd.uci.edu/~gohlke/pythonlibs/</a> and will likely also start<br></div><div class="gmail_extra">to recommend using Anaconda.<br><br></div><div class="gmail_extra">This means we don't have any comparable download metrics<br></div><div class="gmail_extra">to gauge 32 bit vs 64 bit Windows usage, but personally I'm<br>quite happy for NumPy to phase out their 32 bit Windows<br></div><div class="gmail_extra">installers (and then we can do the same).<br><br></div><div class="gmail_extra">I hope we can follow NumPy's lead with wheel distribution etc.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Peter<br><br></div><div class="gmail_extra"><br></div></div>