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

[Emilio Mayorga]

I'm excited to see the progress with the Python bindings namespace,
next-gen as default, etc. Thanks to Hobu and Chris for their excellent
work!

Being a little dense and not too knowledgeable of installation issues,
I'm still unclear about what exactly this will mean for future
installations of GDAL/OGR as a "normal", idiot-proof Python package on
Windows. If I have my own standard Python installation (say, 2.4 or
2.5) and I've installed numpy (available as an idiot-proof
executable), will there be a gdal/ogr executable that I can install
just as easily, bringing in all required gdal/ogr libraries? Or will
there still be a need to compile gdal first, install FWTools, or
something along those lines, at least for the near future?

I want to get an idea of whether gdal-python installation on Windows
will become as simple as the numpy installation. I'm building some
modeling components in Python that will be used by others even more
clueless than I am, so I'd like to know how far we are from the day
when installing a python gdal/ogr package is a simple double-click on
an executable.

Thank you!

-Emilio Mayorga


> From: Howard Butler <hobu.inc at gmail.com>
> To: Gdal-Dev <gdal-dev at lists.maptools.org>
> Date: Thu, 4 Oct 2007 14:03:09 -0500
> Subject: [Gdal-dev] Turn off the old-gen Python bindings in trunk
> 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