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

[Matthew Brett]

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
2) You should use a super-package instead

On those arguments, we should withdraw all binary installers.  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.

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?

Cheers,

Matthew