[Numpy-discussion] Managing Python with NumPy and many external libraries on multiple Windows machines
Charles R Harris
Mon Apr 27 19:56:45 CDT 2009
On Mon, Apr 27, 2009 at 5:40 PM, Robert Kern <firstname.lastname@example.org> wrote:
> On Mon, Apr 27, 2009 at 18:36, Wes McKinney <email@example.com> wrote:
> > On Mon, Apr 27, 2009 at 5:59 PM, Charles R Harris
> > <firstname.lastname@example.org> wrote:
> >> On Mon, Apr 27, 2009 at 3:05 PM, Wes McKinney <email@example.com>
> >>> Hello,
> >>> I am wondering if anyone can offer some suggestions on this problem.
> >>> the last year or so I have been building a number of libraries on top
> >>> NumPy + SciPy + matplotlib and other libraries which are being used for
> >>> investigative research for my company's problem domain in place of,
> >>> 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
> >>> a large number of 3rd-party Python libraries? Upgrading packages right
> >>> 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
> >>> 1.3 was incompatible with 1.2.x.
> >> Out of curiosity, what was the nature of the incompatibility?
> >> Chuck
> > A Cython DLL using the NumPy include and buffer interface (which worked
> > in 1.2.x, too) caused a hard crash on import, I wasn't able to diagnose
> > further.
> We have also encountered a number of segfaults upon import_array() on
> multiple platforms due to an extension module being built against
> numpy 1.3 but being imported after numpy 1.2.
Hmm... OK, I think that is because of the endianess function added to the
API. It is called during module load and since it isn't there for 1.2,
crash. There is also a check for the API version that should have raised an
error, but evidently not. I think the endianess check should probably be
moved to testing and not be done during the load. Or it can simply be
removed from the interface and/or be implemented inline. I don't think
having it in the interface is that important.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion