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
