[Gdal-dev] Turn off the old-gen Python bindings in trunk

[Howard Butler]

All,

It is expected that we will be using the next-gen Python bindings by  
default in the upcoming GDAL 1.5 release.  As we prepare for the  
release, similar to turning on the metadata stuff, I would like to  
turn off building the old-gen Python bindings by default and switch  
to using the next-gen bindings.  I am looking for feedback on doing  
so because there might be some consequences:

- The next-gen bindings are still missing a few methods, but their  
coverage is fairly complete.  For certain scripts, this will cause a  
problem (the missing bits are in some raster operations).  It is  
hoped that we will clean most of these issues up before release time.
- The next-gen bindings use setuptools/distutils for building.  This  
means Python eggs (if you have setuptools installed) and typical  
setup.py operations.  It is quite different than the hand-built model  
we used with ./pymod.
- Building the next-gen bindings in-place with libtool is slightly  
problematic currently.  It is hoped that wider testing will allow us  
to hammer out some of these issues.
- As I stated in a previous email, we now have things in an 'osgeo'  
namespace in the next-gen bindings, but the old imports like 'import  
gdal' still continue to work with a deprecation warning.  For future  
developments, use 'from osgeo import gdal', etc.

Howard