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.bar...@noaa.gov
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
