On Fri, Dec 18, 2015 at 2:51 PM Ralf Gommers <ralf.gomm...@gmail.com> wrote:
> On Fri, Dec 18, 2015 at 5:55 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Fri, Dec 18, 2015 at 2:12 AM, Nathaniel Smith <n...@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@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. Best, -Ian
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
