[Gdal-dev] ng-python build

[Christopher Barker]

My thoughts on Python Bindings Building/installing:

William Kyngesburye wrote:
> As I worked on some OSX framework build issues,

NOTE: Thanks so much for working on this!!

> - After configuring to build ng-python, make doesn't build *any* python 
> bindings. 

> BUT, install does - the 
> install-actions target runs a make install in the swig dir, which ends 
> up building ng-python.

hmmm -- since you can define in configure whether or not you want the 
bindings, I think "make" should build them. Does make call distutils? If 
so, how does it determine which python to call it with?

> - ng-python installs in $prefix.  This ends up being installed 
> where-ever GDAL is installed, in the subdir thereof specified in the 
> python distutils (something like lib/python2.5/site-packages).

I'm confused now -- are they getting installed where GDAL is installed? 
or in site-packages? Anyway, they should get installed in site-packages.

> Shouldn't it be left completely up to distutils so it gets 
> installed in the default python site-packages dir?

Yes.

However, there are two things that get installed:

- The base gdal shared libs themselves
- The python extensions (and python code)

Which are we talking about here?

Anyway, I think the base gdal shared libs should bet installed in a 
"global" location -- on OS-X that would be in Library/Frameworks, and on 
other *nix , in /usr/local/lib (I think).

Howard Butler wrote:
> with the ng bindings, the situation is 
> more inconsistent than that:
> 
> -- If setuptools is installed, use that to build and do "install --root 
> / --single-version-externally-managed".  By default this means an egg 
> file gets put in your Python path (typically site-packages)

Sounds OK.

> -- If setuptools is not installed, install in --prefix as before.

This, I think, should put it in site-packages, like the usual setup.py 
install.

> There are so many different ways to skin this cat now 

Well, yes, but the python world has pretty much two standards now -- 
basic distutils, and setuptools, and, for the most part, people are 
making those two behave similarly -- that's what we should do. (OK, you 
-- I haven't figure out setuptools yet!)

> I think putting stuff in --prefix by default is 
> confusing for most folks, but installing stuff in the root of your 
> Python install isn't too friendly either...

But it is standard behavior. At some point, Apple had set up their 
Python with site-packages outside of the system dirs (maybe in /Library, 
rather than /System/Library), with a soft link into the system Python -- 
this was the "right" thing to do, I think, but it doesn't seem to be 
standard behavior on any other *nix system (and I'm not sure Apple is 
doing it either -- I haven't used Apples python for ages). Anyway, right 
or not, it's up to the distributer of Python to set up -- distutils is 
supposed to put things wherever the python it is run with says it 
should, so we should follow that standard.

> As things are currently defined, setuptools is used *by default* if 
> configure or setup.py determines that it is available. Regular distutils 
> is then used if setuptools isn't available.

sounds good.

> I would hate to *require* setuptools.

Yes, we probably shouldn't -- *sigh* maybe it will make it into the 
standard lib some day....

> Our default 
> install: targets basically install the bindings the same way regardless 
> of whether or not setuptools is available, 

That's probably good.

> My opinions:
> -- I really like setuptools for the 'develop' target and even for eggs 
> now that we use them on the osx buildbot slave (everything is 
> self-contained and it doesn't end up polluting the rest of my machine 
> with new and possibly broken bindings and we don't have to do sys.path 
> hacking). I can see providing the ng bindings as eggs for windows, for 
> example.

I agree -- that is most of the point of eggs after all!

> -- './configure --with-python;make;make install' needs to do the most 
> straightforward thing for Python users

yup.

> (we need to define what that is, 
> and it is my opinion that installing in --prefix *isn't* it).

no, it's not!

I think I've outlined my opinion about what it is above.


> Someone 
> wanting to do fancier stuff should have to run setup.py themselves.

yup.

One more question though: How does configure figure out which python to 
use? should there be a configure option to choose your python? could you 
choose more than one? and have it build them all?

-Chris

> PS.  This discussion reminded me of the best feature of the ng bindings 
> in the upcoming 1.5 release... docs!  I figured out a way to incorporate 
> the doxygen docs into docstrings as part of the swig generation.  pydoc 
> away... :)

cool!


By the way -- William, how are you building the Frameworks?

Is there a configure option ( --framework or something) that tells make 
to build them?

Is a Framework build the default on OS-X? Should it be?

-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