[Gdal-dev] ng-python build

[Jim Klassen]

Thanks for the response.
 
Of the two options, I'd personally prefer running setup.py separately
over a new configure option. Either would work for me. However, I am
somewhat more likely to forget to add the configure option and be
surprised after I run "make install".

>>> On 10/16/2007 at 11:38 AM, Christopher Barker
<Chris.Barker at noaa.gov> wrote:
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 
_______________________________________________
Gdal-dev mailing list
Gdal-dev at lists.maptools.org 
http://lists.maptools.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20071016/e0020b7f/attachment.html