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

[David Cournapeau]

On Thu, Feb 7, 2013 at 7:38 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Thu, Feb 7, 2013 at 11:05 AM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>>
>>
>>
>> On Thu, Feb 7, 2013 at 7:59 PM, Matthew Brett <matthew.brett at gmail.com>
>> wrote:
>>>
>>>
>>> >> Can we defer the Scipy build until after the Numpy build?
>>> >
>>> >
>>> > That doesn't sound like a good idea to me.
>>>
>>> I must say I'm a little confused as to how we're going to make the
>>> decisions here.
>>
>>
>> How about: attempt to reach consensus? David's concern on DLLs hasn't been
>> addressed yet, nor has mine on packages being unavailable. I was actually
>> still answering another of your emails, but I can't seem to reply fast
>> enough.
>
> Right - consensus is good - but at the moment I keep getting lost
> because the arguments seem to shift and get lost, and sometimes they
> are not made.
>
> So, here is the summary as I understand it, please correct if I am wrong
>
> I think we agree that:
>
> 1) Having a binary installer for numpy Windows 64 bit is desirable
> 2) It is desirable to have a matching binary installer for Scipy as
> soon as possible
> 3) It is preferable to build with free tools
> 4) It is acceptable to use non-free tools
> 5) The build will need to do some run-time linking to MKL and / or mingw
> 6) It is preferable that the build should be fully automated
> 7) It is preferable that one person can build all numpy / scipy builds
>
> The points of potential disagreement are:
>
> a) If we cannot build Scipy now, it may or may not be acceptable to
> release numpy now.  I think it is, you (Ralf) think it isn't, we
> haven't discussed that.  It may not come up.
> b) It may or may not be acceptable for someone other than Ondrej to be
> responsible for the Windows 64-bit builds.  I think it should be, if
> necessary, we haven't really discussed that, it may not come up.
> c) It may or may not be acceptable for the build to be only partially
> automated.  Ditto.
> d) It may or may not be acceptable to add the DLL directory to the
> PATH on numpy import.  David says not, Christophe disagrees, we
> haven't really discussed that.

I assumed this was obvious, but looks like it isn't: modifying the
process user environment when importing a python package is quite user
hostile. os.environ is a global variable, and it could cause quite
hard to diagnose issues when something goes wrong.

I would see a library doing this kind of things, especially at import
time, quite badly.

David