[SciPy-Dev] win32 binaries and scipy 0.17.0 release

[Sturla Molden]

I would be in favor of temporarily dropping Windows binary installers 
and wheels. I would be in favor of just distributing the source code, on 
any platform, including Windows, Linux and Mac.

SciPy is even worse off than NumPy with respect to Windows, because it 
also needs a Fortran compiler. Currently the only build tools that 
really works is Intel compilers and MKL. This requires a non-free 
license for the binary distributions.

The official Python 2.7 installer is tied to an outdated version of 
MSVC. Anaconda, Canopy et al. do not have this limitation. They can 
build their own Python with a current version of Visual Studio.

Installing a full SciPy stack and taking care of all dependencies 
requires something like Anaconda or Enthought Canopy anyway. I am not 
sure PyPI is sufficient. This is not just a Windows problem, though.

Python and SciPy on MacOSX has many of the same issues, and we are stuck 
with an outdated gcc based toolchain to make "fat" binaries. Also it 
encourages abuse of the system Python; on El Capitan the system Python 
has a special protection layer preventing package installation. We 
should not encourage anyone to install something into it. Users should 
be adviced to use tools like Anaconda, and it is roughly the same 
situation as we have on Windows.

On Linux the maintainers of the distributions can build and ship 
whatever packages they want, so that is not our problem.

Sturla


On 21/12/15 09:30, Evgeni Burovski wrote:
> Hi,
>
> Here's a proposal to follow the numpy lead
> (https://mail.scipy.org/pipermail/numpy-discussion/2015-December/074422.html)
> and stop providing the official binaries for 32-bit windows.
>
> The reasons are basically the same as for numpy: these binaries
> contain BLAS/LAPACK which is necessarily lower quality than what's
> available from Christoph Gohlke/Canopy/Anaconda; they do not and
> cannot support python 3.5; the build toolchain is currently broken and
> to the best of my knowledge nobody knows how to fix it.
>
> With regards to the scipy 0.17.0 release, win32 problems are
> responsible for delaying the release for almost a month (OK, the
> original schedule was too optimistic, but still).
>
> The alternatives, as I see them, are:
> * stop providing the windows binaries (until a MinGW-64 based
> toolchain is ready, but this is separate) and make the release.
> * release 0.17.0 with only python 3.4 binaries available (this is the
> only python version I can build the binaries which do not segfault
> immediately :-))
> * delay the release with no ETA and no clear path forward.
>
> Thoughts?
>
> Evgeni
>