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

[Tamas Szekeres]

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/30250b8a/attachment.html