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

[Matthew Brett]

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.  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.

> 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.

> 2) Releasing 64 bit numpy without matching scipy binaries would make
> little sense to me.

Would you consider also releasing your scipy binaries?

> 3) Please do not just redistribute the binaries from my website and
> declare them official. They might contain unreleased fixes from git
> master and pull requests that are needed for my work and other packages.

Right - would you consider then being the release provider for numpy /
scipy binaries on windows, much as it appears that Martin v Lowis
supplies Windows builds for Python?

> 4) Numpy-MKL requires the Intel runtime DLLs (MKL is linked statically
> btw). I ship those with the installers and append the directory
> containing the DLLs to os.environ['PATH'] in numpy/__init__.py. This is
> a big no-no according to numpy developers. I don't agree. Anyway, those
> changes are not in the numpy source repositories.
>
> 5) My numpy-MKL installers are Python distutils bdist_wininst
> installers. That means if Python was installed for all users, installing
> numpy-MKL on Windows >6.0 will prompt for UAC elevation. Another no-no?

I defer to others on these ones,

Thanks a lot,

Matthew