[Numpy-discussion] Proposal: stop providing official win32 downloads (for now)

Ralf Gommers ralf.gommers at gmail.com
Fri Dec 18 16:51:31 EST 2015

On Fri, Dec 18, 2015 at 5:55 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

> On Fri, Dec 18, 2015 at 2:12 AM, Nathaniel Smith <njs at pobox.com> wrote:
>> Hi all,
>> I'm wondering what people think of the idea of us (= numpy) stopping
>> providing our "official" win32 builds (the "superpack installers"
>> distributed on sourceforge) starting with the next release.
+1 from me. Despite the number of downloads still being high, I don't think
there's too much value in these binaries anymore. We have been recommending
Anaconda/Canopy for a couple of years now, and that's almost always a much
better option for users.

>> These builds are:
>> - low quality: they're linked to an old & untuned build of ATLAS, so
>> linear algebra will be dramatically slower than builds using MKL or
>> OpenBLAS. They're win32 only and will never support win64. They're
>> using an ancient version of gcc. They will never support python 3.5 or
>> later.
>> - a dead end: there's a lot of work going on to solve the windows
>> build problem, and hopefully we'll have something better in the
>> short-to-medium-term future; but, any solution will involve throwing
>> out the current system entirely and switching to a new toolchain,
>> wheel-based distribution, etc.
>> - a drain on our resources: producing these builds is time-consuming
>> and finicky; I'm told that these builds alone are responsible for a
>> large proportion of the energy spent preparing each release, and take
>> away from other things that our release managers could be doing (e.g.
>> QA and backporting fixes).
> Once numpy-vendor is set up, preparing and running the builds take about
> fifteen minutes on my machine.

Well, it builds but the current setup is just broken. Try building a binary
and running the tests - you should find that there's a segfault in the
np.fromfile tests (see https://github.com/scipy/scipy/issues/5540). And
that kind of thing is incredibly painful to debug and fix.

> That assumes familiarity with the process, a first time user will spend
> significantly more time. Most of the work  in a release is keeping track of
> reported bugs and fixing them. Tracking deprecations and such also takes
> time.
>> So the idea would be that for 1.11, we create a 1.11 directory on
>> sourceforge and upload one final file: a README explaining the
>> situation, a pointer to the source releases on pypi, and some links to
>> places where users can find better-supported windows builds (Gohlke's
>> page, Anaconda, etc.). I think this would serve our users better than
>> the current system, while also freeing up a drain on our resources.
> What about beta releases? I have nothing against offloading part of the
> release process, but if we do, we need to determine how to coordinate it
> among the different parties, which might be something of a time sink in
> itself.

We need to ensure that the MSVC builds work. But that's not new, that was
always necessary for a release. Christophe has always tested beta/rc
releases which is super helpful, but we need to get Appveyor CI to work

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20151218/decfab18/attachment.html>

More information about the NumPy-Discussion mailing list