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

Wed Jan 5 17:43:53 EST 2011

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-bounces at lists.osgeo.org
[mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Tamas Szekeres
Sent: Wednesday, January 05, 2011 4:37 PM
To: Christopher Barker
Cc: gdal-dev at lists.osgeo.org
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

2011/1/5 Christopher Barker <Chris.Barker at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110105/499a4129/attachment-0001.html