<br><br><div class="gmail_quote">2011/1/5 Christopher Barker <span dir="ltr"><<a href="mailto:Chris.Barker@noaa.gov">Chris.Barker@noaa.gov</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
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.<br>
<br></blockquote><div><br>Chris,<br><br>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 <a href="http://www.gdal.org/">http://www.gdal.org/</a><br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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<br>
<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
3) If there is a standard install location, then "easy_install gdal" (or setup.py build, or...) could work for the python bindings.<br>
<br></blockquote><div><br>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, <a href="http://python.org">python.org</a> 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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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 <a href="http://python.org" target="_blank">python.org</a> binaries: 2.6, 2.7, 3.1 (maybe 2.5 too).<br>
<br></blockquote><div><br>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 <a href="http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries">http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries</a> would support this feature though.<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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)<br>
<br></blockquote><div><br>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. <br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
However, I DON'T want gdal to give me Python -- I use Python for too many other things for that.<br>
<br></blockquote><div><br>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.<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<div class="im"><br></div></blockquote>
<div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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.<br>
<br></blockquote><div><br> 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.<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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!<br>
<br></blockquote><div><br>Agreed, but I have no idea either.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Inno Setup is a very nice free installer, by the way.<div><div></div><div class="h5"><br></div></div></blockquote><div><br>I would also add <a href="http://wix.sourceforge.net/">Wix</a> to the list.<br> <br><br></div>Best regards,<br>
<br>Tamas<br><br><br></div><div style="visibility: hidden; left: -5000px; position: absolute; z-index: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 130%;" id="avg_ls_inline_popup">
</div>