<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.2900.3199" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Microsoft Sans Serif">
<DIV>Thanks for the response.</DIV>
<DIV> </DIV>
<DIV>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".<BR><BR>>>> On 10/16/2007 at 11:38 AM, Christopher Barker <Chris.Barker@noaa.gov> wrote:<BR></DIV>
<DIV style="PADDING-LEFT: 7px; MARGIN: 0px 0px 0px 15px; BORDER-LEFT: #050505 1px solid; BACKGROUND-COLOR: #f3f3f3">Jim Klassen wrote:<BR>> I've been watching this from the sidelines and would like to add that at <BR>> St. Paul we have a use for the present behavior of installing the <BR>> bindings next to GDAL.<BR><BR>Thanks for the use case!<BR><BR>> We have multiple versions of GDAL installed on the same machine. We do <BR>> this so we can update GDAL w/o having to worry about breaking any of our <BR>> (web) applications. We can test and move the applications to the new <BR>> version one at a time and without disruption to our users. If the <BR>> bindings are in site-* then how does one control which version of GDAL <BR>> is used?<BR><BR>This has been an issue for years with python modules/packages. For some <BR>completely unknown (to me) reason, the core python developers never <BR>thought it was something worth addressing. The result is that a number <BR>of solutions have been cobbled together by various python package <BR>developers:<BR><BR>1) wxPython has a "wxversion" module, so that you can have multiple <BR>versions installed, and call:<BR><BR>import wxversion<BR>wxversion.select('2.6')<BR>import wx<BR><BR>and get the version you want.<BR><BR>I believe wxGTK has a similar system.<BR><BR>2) there is the workingenv system:<BR><A href="http://cheeseshop.python.org/pypi/workingenv.py">http://cheeseshop.python.org/pypi/workingenv.py</A><BR><BR>That is designed to set up a python environment for a given app that is <BR>kept distinct from the rest of the python stuff on your system -- it may <BR>well be the best solution for a server app (Is that what you're using).<BR><BR>3) Eggs supports version control:<BR><BR><A href="http://peak.telecommunity.com/DevCenter/PythonEggs">http://peak.telecommunity.com/DevCenter/PythonEggs</A><BR><BR>At least I thought they did. They do support requiring a given version:<BR><BR>"""<BR>They allow applications or libraries to specify the needed version of a <BR>library, so that you can e.g. require("Twisted-Internet>=2.0") before <BR>doing an import twisted.internet.<BR>"""<BR><BR>It's not clear to me if that means you can have multiple versions of a <BR>given package installed, and the correct one will be used, but I THINK <BR>that's the case -- more research needed.<BR><BR>As Hobu has been working on setuptools+egg support, that may be the way <BR>to go in the future.<BR><BR>> With the bindings stored with GDAL, we can control which one is <BR>> used by setting [DY]LD_LIBRARY_PATH and PYTHONPATH before calling the <BR>> script.<BR><BR>Maybe it's because I'm a committed pythonista, but I prefer the <BR>python-based approaches to setting up environment variables -- if <BR>nothing else, the python approaches are cross-platform.<BR><BR>That being said, GDAL should support this kind of use. However, I still <BR>don't think that the current behavior is the appropriate default. I'd <BR>like to see a "--python-prefix" option to ./configure, so that folks can <BR>put the python stuff where they want, which may or may not be the same <BR>place as the rest of GDAL.<BR><BR>The other option is to keep it simple, and not have make run setup.py -- <BR>folks can run that themselves, and pass in any path they want.<BR><BR>Would these work for you?<BR><BR>> I don't remember which update caused it, but I am pretty <BR>> sure it wasn't GDAL so maybe we are just being over cautious.<BR><BR>well, maybe -- the GDAL devs are very committed to backward <BR>compatibility -- but it's still good practice to run a production app <BR>with the versions of libs it's been tested with.<BR><BR>-Chris<BR><BR>-- <BR>Christopher Barker, Ph.D.<BR>Oceanographer<BR><BR>Emergency Response Division<BR>NOAA/NOS/OR&R (206) 526-6959 voice<BR>7600 Sand Point Way NE (206) 526-6329 fax<BR>Seattle, WA 98115 (206) 526-6317 main reception<BR><BR>Chris.Barker@noaa.gov<BR>_______________________________________________<BR>Gdal-dev mailing list<BR>Gdal-dev@lists.maptools.org<BR><A href="http://lists.maptools.org/mailman/listinfo/gdal">http://lists.maptools.org/mailman/listinfo/gdal</A>-dev<BR></DIV></BODY></HTML>