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

[Christopher Barker]

On 1/5/11 2:32 PM, Frank Warmerdam wrote:
>  From my perspective, I'm pleased with Tamas' provided binaries as a source
> for developers who want a GDAL SDK for a particular compiler version and
> choice of win32/win64.

yes, those are great!

> Like some others, I'm also confused by the "correct" way of providing
> python binaries. I'm inclined to provide an included python in a self
> installer similar to FWTools,

This is really nice for folks that aren't using Python for other things, 
but if GDAL is only part of your Python tools stack, not so great.

> but I'd be pleased if the hardcore
> Pythonistas can get the magic ways of producing python binaries for any
> Python version working.

I think it's possible, though I'm not sure about "any"! maybe "the most 
common"

> Is there someone that wants to take on producing official GDAL binaries
> from OSGeo4W

I'm confused about what "from OSGeo4w" means, and I don't know that I 
can "take it on", but I've spent enough time on this thread already, I 
should help out!

On 1/5/11 2:43 PM, Jason Roberts wrote:
> 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”.

absolutely true. It's also not that hard to do one of those, once you've 
got the other. Once you've got the .msi building, building a binary egg 
is pretty easy, and then you just have to make sure pypi has the right 
links in place so that people get it with easy_install.

In short, we have one problem to solve, not two.

> 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.

Good summary -- yes, that's pretty much it.

Which is why I'm saying that if we had a "standard" way that GDAL 
binaries got installed, it would be a lot easier. Then it would be:

1) install GDAL binaries
2) either:
   a) download the source for the python bindings and "setup.py build"
or
   b) run "easy_install gdal" (which would download the source and build 
the binary)

> 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.

yup.

On 1/5/11 3:12 PM, Tamas Szekeres wrote:
> Maybe this is due to my lack of knowledge in Python, but why is it a
> requirement to place the files to such specific locations to run a
> python app with gdal on Windows?

well, it's not the only way to do it, but it is the most common way.

> As far as I remember setting up the
> following environment variables properly (in a command prompt) does the
> right thing from arbitrary locations (at least when running the autotest
> suite for GDAL):
>
> PROJ_LIB
> GDAL_DRIVER_PATH
> GDAL_DATA
> PYTHONPATH
> PATH

well -- first of all, setting environment variables on Windows is a 
PITA, second of all, is setting all that up easier than what Jason 
described?, and third, PYTHONPATH is a problem, particularly if you have 
more than one version of python installed.

So I think Jason's way is a better option, but it really would be nice 
to do an installer.

so what to do?

This is all complicated because GDAL is many things:
  - a lib that can be used to build your own C/C++, etc. apps
  - a set of command line utilities
  - a python package
  - a package for various other languages
  - a set up utilities written in Python, also.

Being a Pythonista, I'll focus on the Python bits

Question 1:

   Do we want:
a) a binary package for the python bindings that is completely 
stand-alone -- i.e. has its own copy of everything GDAL that it needs, 
and does not share the dlls with anythign else.

b) (a) but sharing the dlls with other things that may need gdal? (other 
language bindings, mapserver, what have you)

c) (a) or (b) plus the python command line tools

d) (a), (b), or (c) plus the compiled command line tools.


As I write this, I realize that maybe using or following OSGeo4w is the 
way to go -- put the gdal binaries wherever OSGeo4w puts them, and 
building the python bindings against that. Essentially letting OSGeo4w 
establish the standard.

To Tamas:

I wonder if there is some confusion about how the python bindings are 
used. You've referred to "setting up an application", making me think 
that you're talking about how to install an application, written in 
Python, that uses GDAL. IN that case I think you've got it right.

However, what I'm thinking of is python developers, casual scripters. In 
this case you want to install python-gdal, and be able to fire up the 
interpreter and type "from osgeo import gdal" and away you go. For that 
use case, Jason has described the install process quite well.

I'm going to do an upgrade/install on my Windows box (actually, I'm 
going to try a VM...) and keep notes to see if I can get it boiled down 
to a precise and repeatable process.

-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.Barker at noaa.gov