[Numpy-discussion] [SciPy-user] Managing Python with NumPy and many external libraries on multiple Windows machines

Charles R Harris charlesr.harris@gmail....
Tue Apr 28 10:45:11 CDT 2009

On Tue, Apr 28, 2009 at 9:41 AM, David Cournapeau <cournape@gmail.com>wrote:

> On Tue, Apr 28, 2009 at 11:58 PM, Travis Oliphant
> <oliphant@enthought.com> wrote:
> >
> > On Apr 27, 2009, at 4:05 PM, Wes McKinney wrote:
> >
> >> Hello,
> >>
> >> I am wondering if anyone can offer some suggestions on this problem.
> >> Over the last year or so I have been building a number of libraries
> >> on top of NumPy + SciPy + matplotlib and other libraries which are
> >> being used for investigative research for my company's problem
> >> domain in place of, say, Matlab and R (which are more "ready out of
> >> the box" systems). I have approximately 20 users, all of whom are
> >> running Windows on a very Microsoft-centric network with databases,
> >> etc. Has anyone had any luck managing a standardized Python
> >> environment on lots of Windows machines with a large number of 3rd-
> >> party Python libraries? Upgrading packages right now involves
> >> getting 20 people to click through an .exe installer, which is
> >> hardly a good solution. For example, I was recently forced to
> >> upgrade everyone's NumPy to 1.3 after I discovered that a DLL I had
> >> built against 1.3 was incompatible with 1.2.x.
> >
> > There has been a good discussion of this with others.   I'm pretty
> > sure we had fixed this in NumPy so at least you would get a sane error
> > instead of a segfault.   The solution may not be ideal and it can be
> > hard to remember to edit the right place in the headers when a change
> > is made so it may not have been done for 1.3
> Maybe we could supplement the manual editing: the code generators
> should guarantee the order of each item of the API, so the number of
> items in the array is enough to compare to API. So if we implement a
> guard in the PyArray_API, we could dynamically check the number of
> items in the array, and check it against the pre-computed number. A
> different number means incompatible API.

That will work as long as we maintain backward compatibility. If we change
the ABI at some point we will need something stronger.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20090428/f7c2ade9/attachment.html 

More information about the Numpy-discussion mailing list