[gdal-dev] Re: KyngChaos Frameworks: GDAL's numpy vs Enthought's numpy

K.-Michael Aye kmichael.aye at gmail.com
Mon Apr 19 13:23:34 EDT 2010

> 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?

BTW, this is my sys.path:










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! ;)

>> Am I guessing right, that the only remedy would be to build GDAL 
>> forNumpy 1.4 on my own?
>> Or would it be more recommendable to find an old Enthought, that 
>> stilluses Numpy 1.3?
> It's not [Enthought] python that's using numpy, it's GDAL and 
> otherpython programs.  As long as the python version matches, it should 
> work,though there can be other incompatibilities in different python 
> builds.

Clear. And I guess the culprit is the matplotlib included in Enthough 
demanding a certain version of numpy?

>> 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.

> You could try copying my gdal.pth to Enthought's user site-packages, 
> soit should override Enthought's numpy, but that will happen for all 
> otherpython usage iwth Enthought's python.

As reported, that's what I did anyway, but then my beloved -pylab 
switch (and maybe much more in Enthought) does not work anymore.

> I just figured out that I could customize the GDAL python to force it 
> toload the framework copy of numpy, but I'd also then probably 
> isolatethat numpy from the python path.  I may try that in the next 
> release.

Sounds worth a try, especially as you state, that GDAL should not mind!

Thanks for your time! But what do you recommend I should do now? Should 
I wait for a release from you, or is there a 'bridge'-solution possible?

Best Regards,

More information about the gdal-dev mailing list