Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

[Christopher Barker]

On 1/6/11 3:03 PM, Joaquim Luis wrote:
> Also a word about the "best practice on Windows". I really don't see
> anything not even good in that practice to put them in "Program Files".
> Having directories with blanks in their name give nothing but future
> problems when running command line programs (I have seen that happen
> many times).

True, I'm still quite amazed how MS has ignored the command line for 
years. Sure, we geeks are a small fraction of Windows users, but a small 
fraction of a huge userbase is still a LOT.

Perhaps that's why the standard place for Python is NOT in "Program Files"

That being said, "Program Files" does seem to work fine for me most of 
the time.

> Time to time, it has been raised also the hypothesis to put the dlls in
> windowes\system32. PLEASE, PLEASE don't even think on that.

That, we do have a consensus on!

By the way, isn't there some new stuff about "side by side" installs or 
something -- that's supposed to help dll hell?

On 1/6/11 2:49 PM, Frank Warmerdam wrote:
> I don't have a strong position on this, but I would note that beyond
> real Python programmers wanting to use the bindings, they are also needed
> just to run the python commandline utilities (such as rgb2pct.py). So
> there is definately a large body of folks who would benefit from having
> working python for the python utilities, and the regular commandline
> executables.

yup. Also, I use gdal command line utilities and python bindings. It's 
actually really nice to know that they are using the exact same 
versions, as I can test stuff with the utilities and compare results.

> Another benefit of even Python using GDAL from a standard location is
> things like format plugins could be easily handled in one place.

Yes, and then Perl, and who knows what else can share the same install.

> Actually, the more I think about it, the more I prefer even the Python
> bindings to use the GDAL under \Program Files\GDAL.

+1 from me, too.

I winder where Howard is? But anyway, the gdal PyPi site (which I think 
Howard wrote/maintained) says:

"""
Windows

You will need the following items to complete an install of the GDAL 
Python bindings on Windows:

     * GDAL Windows Binaries The basic install requires the 
gdalwin32exe###.zip (### is the version number). Other files you see in 
the directory are for various optional plugins and development 
headers/include files. After downloading the zip file, extract it to the 
directory of your choosing.
"""

** the problem here is that that zip file hasn'tbeen maintained for a while.

"""
     * GDAL Python Bindings available at the Python Cheeseshop. An 
executable installer is available for both Python 2.4 or 2.5 or as a 
Python egg.
"""
** this is pretty much what Jason is suggeting - a binary egg dependent 
on a certain gdal install.

"""
As explained in the README_EXE.txt file, after unzipping the GDAL 
binaries you will need to modify your system path and variables. If 
you're not sure how to do this, read the Microsoft KnowledgeBase doc

    1. Add the installation directory bin folder to your system PATH, 
remember to put a semicolon in front of it before you add to the 
existing path.

       C:\gdalwin32-1.7\bin

    2. Create a new user or system variable with the data folder from 
your installation.

       Name : GDAL_DATA
       Path : C:\gdalwin32-1.7\data
"""

It would be nice to remove these steps. Again, I think Jason's got some 
good ideas for that.


By the way -- it is fairly common for python packages to include command 
line utilities. There are tools in distutils and setuptools to support 
that -- they get installed in a Scripts directory in the Python install. 
Should the Python-based gdal utilities go there?

-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