[Gdal-dev] ng-python build

[Christopher Barker]

Jim Klassen wrote:
> I've been watching this from the sidelines and would like to add that at 
> St. Paul we have a use for the present behavior of installing the 
> bindings next to GDAL.

Thanks for the use case!

> We have multiple versions of GDAL installed on the same machine. We do 
> this so we can update GDAL w/o having to worry about breaking any of our 
> (web) applications. We can test and move the applications to the new 
> version one at a time and without disruption to our users. If the 
> bindings are in site-* then how does one control which version of GDAL 
> is used?

This has been an issue for years with python modules/packages. For some 
completely unknown (to me) reason, the core python developers never 
thought it was something worth addressing. The result is that a number 
of solutions have been cobbled together by various python package 
developers:

1) wxPython has a "wxversion" module, so that you can have multiple 
versions installed, and call:

import wxversion
wxversion.select('2.6')
import wx

and get the version you want.

I believe wxGTK has a similar system.

2) there is the workingenv system:
http://cheeseshop.python.org/pypi/workingenv.py

That is designed to set up a python environment for a given app that is 
kept distinct from the rest of the python stuff on your system -- it may 
well be the best solution for a server app (Is that what you're using).

3) Eggs supports version control:

http://peak.telecommunity.com/DevCenter/PythonEggs

At least I thought they did. They do support requiring a given version:

"""
They allow applications or libraries to specify the needed version of a 
library, so that you can e.g. require("Twisted-Internet>=2.0") before 
doing an import twisted.internet.
"""

It's not clear to me if that means you can have multiple versions of a 
given package installed, and the correct one will be used, but I THINK 
that's the case -- more research needed.

As Hobu has been working on setuptools+egg support, that may be the way 
to go in the future.

> With the bindings stored with GDAL, we can control which one is 
> used by setting [DY]LD_LIBRARY_PATH and PYTHONPATH before calling the 
> script.

Maybe it's because I'm a committed pythonista, but I prefer the 
python-based approaches to setting up environment variables -- if 
nothing else, the python approaches are cross-platform.

That being said, GDAL should support this kind of use. However, I still 
don't think that the current behavior is the appropriate default. I'd 
like to see a "--python-prefix" option to ./configure, so that folks can 
put the python stuff where they want, which may or may not be the same 
place as the rest of GDAL.

The other option is to keep it simple, and not have make run setup.py -- 
folks can run that themselves, and pass in any path they want.

Would these work for you?

> I don't remember which update caused it, but I am pretty 
> sure it wasn't GDAL so maybe we are just being over cautious.

well, maybe -- the GDAL devs are very committed to backward 
compatibility -- but it's still good practice to run a production app 
with the versions of libs it's been tested with.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov