[Numpy-discussion] Any plans for windows 64-bit installer for 1.7?
Thu Feb 7 15:05:22 CST 2013
On Thu, Feb 7, 2013 at 7:38 PM, Matthew Brett <email@example.com> wrote:
> On Thu, Feb 7, 2013 at 11:05 AM, Ralf Gommers <firstname.lastname@example.org> wrote:
>> On Thu, Feb 7, 2013 at 7:59 PM, Matthew Brett <email@example.com>
>>> >> 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
> 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.
More information about the NumPy-Discussion