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
/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages
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:


'/Library/Frameworks/Python.framework/Versions/6.1/bin',
'/Users/aye/Library/Python/2.6/site-packages/pydot-1.0.2-py2.6.egg',
'/Users/aye/Library/Python/2.6/site-packages/pyparsing-1.5.2-py2.6.egg',
'/Users/aye/Library/Python/2.6/site-packages/simplejson-2.0.9-py2.6.egg',
'/Users/aye/Library/Python/2.6/site-packages/python_twitter-0.6-py2.6.egg',
'/Users/aye/Library/Python/2.6/site-packages/Sphinx-0.6.3-py2.6.egg',
'/Users/aye/Library/Python/2.6/site-packages/docutils-0.6-py2.6.egg',
'/Users/aye/Library/Python/2.6/site-packages/Jinja2-2.2.1-py2.6.egg',
'/Users/aye/Library/Python/2.6/site-packages/Pygments-1.1.1-py2.6.egg',
'/Users/aye/Library/Python/2.6/site-packages/spyder-1.0.3-py2.6.egg',

'/Users/aye/Library/Python/2.6/site-packages/scikits.image-0.2.2-py2.6-macosx-10.5-i386.egg',


'/Users/aye/Library/Python/2.6/site-packages/PyXML-0.8.4-py2.6-macosx-10.6-universal.egg',


'/Users/aye/Library/Python/2.6/site-packages/pyfo-0.6-py2.6.egg',

'/Users/aye/Library/Python/2.6/site-packages/Amara-2.0a4-py2.6-macosx-10.6-universal.egg',


'/Users/aye/Library/Python/2.6/site-packages/setuptools-0.6c11-py2.6.egg',
'/Users/aye/Library/Python/2.6/site-packages/distribute-0.6.10-py2.6.egg',
'/Users/aye/Library/Python/2.6/site-packages/pip-0.6.3-py2.6.egg',
'/Library/Frameworks/Python.framework/Versions/6.1/lib/python26.zip',
'/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6',
'/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/plat-darwin',
'/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/plat-mac',

'/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/plat-mac/lib-scriptpackages',


'/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/lib-tk',
'/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/lib-old',
'/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/lib-dynload',

'/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages',


'/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/PIL',


'/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg-info',


'/Users/aye/Library/Python/2.6/site-packages',

'/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/IPython/Extensions',


u'/Users/aye/.ipython']

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,
Michael



_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to