Specifically regarding Python programmers who primarily or exclusively use Windows:
The majority of popular Python packages are delivered to Windows users by one of two mechanisms: 1. A stand-alone installation program (either a .exe or .msi file) that the user just downloads and runs, often built with the Python "distutils" technology. 2. The easy_install mechanism, in which the user starts a shell and types "easy_install xxxxx". Most Windows users are not familiar with the UNIX way of doing things, in which the package is compiled and installed from a script. Most Windows users do not even have a C compiler on their machine. As evidence for the popularity of #1, just look at the installation statistics for popular packages such as scipy or numpy. For example, the Python 2.6 .exe installer for scipy 0.8.0 currently has 28417 downloads, while the source code (.tar.gz file) currently has 14403 downloads. As UNIX users will be downloading the source code and not the Windows executable, the 14403 is likely to be a lot of UNIX users and few Windows users. As you can see, the vast majority of Windows scipy users prefer to install it via the GUI installation program rather than the source code. Right now, to install the latest GDAL for Python on Windows, the user has to download a zip file from http://vbkto.dyndns.org/sdk/, drill in to find the Python files, copy them to C:\PythonXX\Lib\site-packages, drill into find the GDAL binaries and related files, copy them to a directory such as C:\GDAL, set the PATH and GDAL environment variables, and so on. And there are no obvious instructions anywhere about how to do this. Python programmers are programmers after all, so they can generally figure that out and accomplish it. But it is not what they are used to doing if they are a Windows programmer. This is why Chris basically says that he has to remember / relearn how to do it every time he upgrades GDAL. It would be really helpful to Windows Python programmers who want to use GDAL-probably a large number of potential GDAL users-for the GDAL team to offer installation via one or both of the mechanisms I mentioned above. Best, Jason From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Tamas Szekeres Sent: Wednesday, January 05, 2011 4:37 PM To: Christopher Barker Cc: gdal-dev@lists.osgeo.org Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0 2011/1/5 Christopher Barker <chris.bar...@noaa.gov> 1) It would be nice to have binaries for the latest release front and center at the main GDAL site -- having to poke around to find Tamas's site is not a big deal, but not always obvious. Chris, With regards to the comment above, while I'm not sure about the objectives but I don't think the GDAL site would intend to be a hosting provider of various binary packages, the most reasonable thing is to put the references pointing the user to the correct locations which has already been done, see the "Downloads" section at http://www.gdal.org/ 2) A standard install location would be good. As I've messed with this each time, I never know where stuff should go -- maybe installers would help with that This doesn't seem to be decisive requirement to me. We may also create a definite location in the hard drive to host such files (which can be remembered later). Or some other folks may prefer installing these files along with their applications or keep such files in separate - project specific - directories. We may also have a requirement to deploy and run these applications from portable locations (ie. from CD or a flash drive). Another issue of an installer may be due to a single product key along with the setup which would prevent from installing multiple versions side by side in the same environment. 3) If there is a standard install location, then "easy_install gdal" (or setup.py build, or...) could work for the python bindings. I admit I don't have enough knowledge about the 'magic' tricks related to python-ish way installing applications. I expect that most 'magic' are implemented by copying the files at certain locations, setting some environment variables or regkey entries. However I might also consider running a custom application with gdal not necessarily be the responsibility of a GDAL package. You might also want to install python from a separate installer (either ActivePython, python.org whatever) and run the application direcly from a command prompt where the environments are set to run the gdal applications properly. Most of these packages provide the required .bat file to setup the environment this way. Another option is to have a binary installer for the python bindings that includes gdal and the gdal utilities -- that would be great for users like me, but I don't know how common my use case is. In that case, you'd want to support a few recent pythons versions, the python.org binaries: 2.6, 2.7, 3.1 (maybe 2.5 too). I don't know much about this either. This may however be doable for those guys who know the Python packaging approach well enough. I don't think eiter of the packages referred at http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries would support this feature though. One of the tricks here is which numpy to support, etc. numpy has been pretty good with binary compatibility lately (except for one mistake recently that was corrected) Not sure how this be related to a GDAL binary distribution, as far as I remember numpy can be installed to the Python deployment directly. However, I DON'T want gdal to give me Python -- I use Python for too many other things for that. Yes, adding more runtime environments to a simple GDAL package makes it more heavy weighted. Would also be reasonable to include the Perl environment or a .NET framework installer for example to make it more complete. However, in many cases it's more reasonable to let the application (using the GDAL binaries) decide how to make a proper installer to run their application smoothly. 4) it might be nice if the install location for the utilities got put on the user's PATH -- I don't know how hard that is in an installer -- Windows really sucks in that regard. I don't think it would be beneficial in most cases. This could easily break other applications (using the dll-s with the same names) to fail unexpectedly. I would prefer to keep the applications isolated (setting the environment variables specifically to the process and not the user/system) as much as possible. An installer would better enforce a standard install location. You could also have a custom DOS box with a menu entry that set up the environment for the command line tools (maybe only PATH?), provide an uninstaller, and of course, give the Windows users a nice warm and fuzzy feeling. The 'nice warm and fuzzy feeling' is a good objective indeed, setting up an entry on the start menu instead of a running the batch file directly may also be an advantage. While I'm not sure starting a DOS prompt would validate an installer by it's own, I can see this requirement to be valid in most cases. With regard to Python, an installer could see what Python the user has and install the bindings for that version. Not that I have any idea how to build that! Agreed, but I have no idea either. Inno Setup is a very nice free installer, by the way. I would also add Wix <http://wix.sourceforge.net/> to the list. Best regards, Tamas
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev