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

Ian Henriksen insertinterestingnamehere at gmail.com
Fri Dec 18 17:22:45 EST 2015

On Fri, Dec 18, 2015 at 2:51 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:

> 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
> soon.
> Ralf
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion

An appveyor setup is a great idea. An appveyor build matrix with the
various supported MSVC versions would do a lot more to prevent
compatibility issues than periodically building installers with old
versions of
MinGW. The effort toward a MinGW-based build is valuable, but having a
CI system test for MSVC compatibility will be valuable regardless of where
things go with that.

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

More information about the NumPy-Discussion mailing list