[gdal-dev] Re: KyngChaos Frameworks: GDAL's numpy vs Enthought's
woklist at kyngchaos.com
Mon Apr 19 14:15:39 EDT 2010
On Apr 19, 2010, at 12:23 PM, K.-Michael Aye wrote:
>> GDAL python *should* be able to use a later version of numpy than it wasbuilt for, it's only the python side of the interface that it caresabout, but I don't know what be happening at compile time that mightlock it in to a specific version of numpy, and python can be picky.
>> If you are including the GDAL framework python folder in the Enthoughtpython path, then numpy 1.3 is also available from there. But dependingon how you added GDAL to the path, numpy might be overridden byEnthought's path. My installer puts a .pth file in the/Library/Python/2.x/site-packages folder that forces it to the top ofthe path. A standard .pth (including the /Library site-packages),oddly, gets added *after* the system paths, so they can't override thesystem modules.
> As Enthought, by default at least, does not look at /Lib.../Python/2.x/site-packages, I copied your gdal.pth to
> After a restart of the Terminal and start of ipython, an
> import numpy
> imports numpy 1.3.0 from the GDAL framework as confirmed by numpy.__version__ and numpy.__path__
> I now can open a gdal dataset and get it's data, but a
> import matplotlib.pyplot as plt
> crashes ipython with this Bus Error.
> Same happens when I start ipython with the -pylab switch (as that switch executes that previous line, among other things.)
> I am also guessing, that the over-write of Enthought's numpy import is not a good thing for the other libraries Enthought is using?
Yes, as I said, copying the gdal.pth will change *all* python programs to use the GDAL numpy within Enthought python.
But this at least confirms some ABI incompatibility as others have mentioned, and Enthought includes the ABI-breaking numpy 1.4.0.
> I posted this problem as well in the matplotlib list, as only the matplotlib pylab switch seemed to crash, here is what
> Robert Kern (from matplotlib?) said to this:
> "[...] Only one version ever gets imported, but the GDAL
> Python bindings expect its version and matplotlib expects another version."
> and recommended as a remedy to
> "rebuild the GDAL Python bindings against Enthought's numpy."
> Obviously I'd like to avoid that, if I can! ;)
>>> Then I should be able to import gdal into the Enthought's Python,right?
>>> Any advise would be appreciated!
>> I generally keep up to date, but I guess I don't check numpy very oftenand didn't see the v1.4 (interesting, they skipped 1.4.0). Though thatis only an RC release yet, so I may still wait for a final release.
> Yes, as was said, 1.4.0 created A LOT of fuss in the world, so they backstepped, officially withdraw it even, I think.
> Interestingly, Enthought's numpy states 1.4.0.
Well, since numpy 1.4.0 is officially un-released, for now you could consider it a bug to be worked around until Enthought updates to numpy 1.4.1. When that happens, GDAL, matplotlib and others should be happy with either 1.3 or 1.4.1.
A workaround you could try: insert the line from the gdal.pth right before the "import numpy" lines in gdalnumeric.py and gdal_array.py. And remove the gdal.pth copy from the Enthought python site-packages. This should make GDAL load its numpy, and leave the sys.path alone for everything else.
If you need to use GDAL with some other python module that uses numpy, in the same script, or in the same session, this could still be a problem. maybe importing the other module before gdal would work.
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
"I ache, therefore I am. Or in my case - I am, therefore I ache."
More information about the gdal-dev