[Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Ralf Gommers]

On Wed, Feb 6, 2013 at 8:46 PM, Matthew Brett <matthew.brett at gmail.com>wrote:

> Hi,
>
> On Wed, Feb 6, 2013 at 10:48 AM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
> >
> >
> >
> > On Wed, Feb 6, 2013 at 1:32 AM, Matthew Brett <matthew.brett at gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> On Tue, Feb 5, 2013 at 3:04 PM, Christoph Gohlke <cgohlke at uci.edu>
> wrote:
> >> > On 2/5/2013 10:51 AM, Matthew Brett wrote:
> >> >> Hi,
> >> >>
> >> >> On Mon, Feb 4, 2013 at 5:09 PM, Matthew Brett <
> matthew.brett at gmail.com>
> >> >> wrote:
> >> >>> Hi,
> >> >>>
> >> >>> On Mon, Feb 4, 2013 at 3:46 PM, Charles R Harris
> >> >>> <charlesr.harris at gmail.com> wrote:
> >> >>>>
> >> >>>>
> >> >>>> On Mon, Feb 4, 2013 at 4:04 PM, Robert Kern <robert.kern at gmail.com
> >
> >> >>>> wrote:
> >> >>>>>
> >> >>>>> On Mon, Feb 4, 2013 at 10:38 PM, Matthew Brett
> >> >>>>> <matthew.brett at gmail.com>
> >> >>>>> wrote:
> >> >>>>>> Hi,
> >> >>>>>>
> >> >>>>>> On Mon, Feb 4, 2013 at 1:15 PM, Ralf Gommers
> >> >>>>>> <ralf.gommers at gmail.com>
> >> >>>>>> wrote:
> >> >>>>>
> >> >>>>>>> MSVC + Intel Fortran + MKL, yes. But those aren't free. So how
> can
> >> >>>>>>> you
> >> >>>>>>> provide an Amazon image for those?
> >> >>>>>>
> >> >>>>>> You can make an image that is not public, I guess.   I suppose
> >> >>>>>> anyone
> >> >>>>>> who uses the image would have to have their own licenses for the
> >> >>>>>> Intel
> >> >>>>>> stuff?   Does anyone have experience of this?
> >> >>>>>
> >> >>>>> You need to purchase one license per developer:
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> http://software.intel.com/en-us/articles/intel-math-kernel-library-licensing-faq#eula1
> >> >>>>>
> >> >>>>
> >> >>>> I think 64 bits on windows is best pushed off to 1.7.1 or 1.8. It
> >> >>>> would be a
> >> >>>> bit much to get it implemented in the next week or two.
> >> >>>
> >> >>> The problem with not providing these binaries is that they are at
> the
> >> >>> bottom of everyone's stack, so a delay in numpy holds everyone back.
> >> >>>
> >> >>> I can't find completely convincing stats, but it looks as though 64
> >> >>> bit windows 7 is now the most common version of Windows, at least
> for
> >> >>> Gamers [1] around now, and it was getting that way for everyone in
> >> >>> 2010 [2].
> >> >>>
> >> >>> It don't think it reflects well on on us that we don't appear to
> >> >>> support 64 bits out of the box; just for example, R already has a 32
> >> >>> bit / 64 bit installer.
> >> >>>
> >> >>> If I understand correctly, the options for doing this right now are:
> >> >>>
> >> >>> 1) Minimal cost in time : ask Christophe nicely whether we can
> >> >>> distribute his binaries via the Numpy page
> >> >>> 2) Small cost in time / money : pay for licenses for Ondrej or me or
> >> >>> someone to install the dependencies on my Berkeley machine / an
> Amazon
> >> >>> image.
> >> >>
> >> >> In order not to leave this discussion without a resolution:
> >> >>
> >> >> Christophe - would you allow us to distribute your numpy binaries for
> >> >> 1.7 from the numpy sourceforge page?
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Matthew
> >> >
> >> >
> >> > I am OK with providing 64 bit "numpy-MKL" binaries (that is numpy
> >> > compiled with MSVC compilers and linked to Intel's MKL) for official
> >> > numpy releases.
> >>
> >> Thank you - that is great.
> >>
> >> > However:
> >> >
> >> > 1) There seems to be no real consensus and urge for doing this.
> >>
> >> I certainly feel the urge and feel it strongly. As a packager for two
> >> or three projects myself, it's a royal pain having to tell someone to
> >> go to two different places for binaries depending on the number of
> >> bits of their Windows.
> >
> >
> > If you're relying on .exe installers on SF, then you have to send your
> users
> > to more places than that probably. Really the separate installers are a
> poor
> > alternative to the available scientific distributions. And the more
> packages
> > you need as a user, the more annoying these separate installers are.
> >
> >>
> >>  I think Chuck was worried about the time it
> >> would take to do it, and I think you've already solved this problem.
> >> Ralf was worried about Scipy - see below.
> >
> >
> > Not just Scipy - that would be my worry number one, but the same holds
> for
> > all packages based on Numpy. You double the number of Windows installers
> > that every single project needs to provide.
> >
> >>
> >>
> >> > Using a
> >> > free toolchain capable of building the whole scipy-stack would be much
> >> > preferred.
> >>
> >> That's true, but there seems general agreement this is not practical
> >> in the very near future.
> >>
> >> > Several 64 bit Python distributions containing numpy-MKL are
> >> > already available, some for free.
> >>
> >> You mean EPD and AnacondaCE?   I don't think we should withhold easily
> >> available vanilla builds because they are also available in
> >> company-sponsored projects.  Python.org provides windows builds even
> >> though ActiveState is free-as-in-beer.
> >
> >
> > If the company-sponsored bit bothers you, there's also a 64-bit
> Python(x,y)
> > now.
>
> I'm sure you've seen that the question 'where are the 64-bit
> installers' comes up often for Numpy.
>
> It seems to me that we'd have to have a good reason not provide them.
> There will always be some number of people like me who like to install
> the various parts by hand, and don't like using large packages, free
> or or open or not.  For example, I don't use macports.  At the moment,
> the reasons I see you are giving are:
>
> 1) Then everyone would have to provide 64-bit binaries
>

Indeed. And since many packages won't do that because there's no free
compilers, users just get stuck a bit later in the "installing the stack"
process. I'm sure providing the binaries will help some people, but I
expect it to cause as many problems as it solves.

Maybe there's a volunteer to help with building official binaries for a
large number of packages? If not, I'm simply not convinced that this will
be a net gain for users.

2) You should use a super-package instead
>
> On those arguments, we should withdraw all binary installers.


32-bit is a very different situation.

Or withdraw the 32-bit ones, on the basis that 64-bit is likely the more
> common now.  Of course we shouldn't do that, because it will put off
> some measurable number of users, and convey the impression that the
> numpy stack is a bit shaky, because it cannot be easily installed
> without a monolithic build framework.


The installation of Python-based stacks *is* a bit shaky, that's no big
secret.

Ralf


> I think that's a real shame, and would harm numpy, to no benefit.
>
> I guess I'm saying, please, please, pretty please, oh please oh please
> oh please can we have a Windows 64-bit installer?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130206/71688935/attachment.html>