[PYTHON MATRIX-SIG] Data analysis package question

[Geoffrey Furnish]

Konrad Hinsen writes:
 > > PLplot is a bear to compile. I've had a fair amount of experience working 
 > > with large software projects, and getting PLplot to the point where I 
 > > could use it, in or out of python, took a significant amount of work. Way 
 > > too much, in my opinion. And it even uses gnu configure.
 > 
 > I have to agree. I tried PLplot a few months ago, but it took forever
 > just to get everything compiled, and the prospect of having to
 > do this repeatedly (new machines, new versions) made be prefer to
 > live without it.

With all this public bashing of the PLplot configuration support, I
think I have to point out some facts which will be missed by people
who have never actually tried it and are going to be very disuaded by
statements like this, which I personally regard as fairly
exaggerated.  Here's why:

First, it is certainly unarguable that PLplot's configuration script
(GNU autoconf based), has historically had a lot of trouble correctly
identifying every single part of a user's supporting environment
during autoconfiguration.  And I won't deny the frustration many have
felt, including the two quoted above.

However, you have to understand clearly that the /worst possible case/
with PLplot is exactly the /standard/ case with Python and NumPy
itself.  In particular, PLplot's configure works very hard to
automatically detect the presence and version number of all the
supporting libraries the user may have.  X11, Tcl/Tk, Python, and
others, all fall into this category.  And it is true, I admit, that
PLplot's configure has, on some systems, had trouble sorting it all
out.

Note, however, that both Python and NumPy, make absolutely no effort
whatsoever to "auto detect" this kind of stuff.  For instance, say you
are building python on a system on which you have already installed
Tcl/Tk.  Is Tkinter automatically configured?  No.  No attempt
whatsoever is made to find your Tcl/Tk, and edit your Setup to turn on
the compilation of the Tkinter module.  You have to do it by hand,
editing Setup, changing the lines for the tkinter module, filling in
correct path information, etc.  You have to edit _tkinter.c by hand to
patch in package initializations which Python doesn't know about, etc.
When you install NumPy, does it look to see if you have a precompiled
FFTPACK sitting around?  No.  The instructions suggest you use the C
version provided, and if you want to use some other version, you have
to edit the setup by hand.  No big deal.  Nobody complains about this,
and neither do I.

And that situation, is the worst possible situation with PLplot.  If
autoconf doesn't do all the magic for you, you get to do it by hand.
If you try to compile PLplot against Tcl 6.7 and Tk 3.6, and you have
trouble, the situation is no different than if you did the same
blunder with Python's Tkinter.  Etc.

What PLplot does do, that neither Python nor NumPy do, is try very
hard to sort out what you have on your system, and autoconfigure
everything possible.  For large numbers of people (read, thouusands)
this has worked adequately.  For some, it has failed miserably.  For
those unlucky souls, the worst thing that happens is they have to make
a barebones makefile, and edit it by hand, which is exactly what
/everyone/ has to do with Python and NumPy themselves.

And, moreover, I have recently corrected dozens of autodetection bugs
in PLplot's configure, so that the number of "unlucky souls" will be
substantially lower than it was before.  

Anyone who /still/ has major problems with the PLplot autoconf
situation is respectfully invited to air their grievances on the
PLplot mailing list, where there are plenty of people who could help
them with valuable advice.

-- 
Geoffrey Furnish		email: furnish@llnl.gov
LLNL X/ICF			phone: 510-424-4227	fax: 510-423-6172

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================