[gdal-dev] Re: KyngChaos Frameworks: GDAL's numpy vs Enthought's
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
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
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
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?
More information about the gdal-dev