matplotlib-devel Mailing List for matplotlib

On Thu, Nov 18, 2010 at 5:57 PM, Benjamin Root <ben...@ou...> wrote:
> I think we are more asking what tutorials have you read to help install
> matplotlib (some are better than others)
This was about 6 weeks ago, and I no longer remember the details. I do
remember I read *a lot* of advice on installing matplotlib (and scipy,
ipython, etc.), not always consistent.
> In addition, what version of MacOS X are you using and if you are using the
> built-in python interpreater or installed your own?
I'm using 64-bit Snow Leopard. My python is /usr/bin/python, which came
with the Snow Leopard installation.
> Did you try the DMG file, or from macports, or from pypi?
>
Don't recall what I finally ended up with, but I do know that I had to
completely scrap the macports install, because my macports got totally
wedged (circular dependencies, etc.). I had to uninstall *all* my macports,
and reinstall them from scratch. On this re-install I did not install any
Python ports, although python2.6 and a few other python ports were pulled in
as dependencies of other ports. Still, even though I have
/opt/local/bin/python2.6, I don't use it.
What we really need is improved documentation for the mac install process.
>
I beg to differ: what we need is a single *official* download and
installation procedure. Of course, this in turn requires a similarly
unitary-no-two-ways-about-it download and installation procedure for
everything else that matplotlib depends on, directly or indirectly. Without
this, adequate documentation becomes impossible, because there's no way that
the writers of the documentation can possibly test the combinatorial
explosion of possibilities.
It's bad enough that we have to deal with multiple OSs and architectures.
 We don't need to pile 31 installation flavors on top of that.
(What really boggles the mind is that of all languages out there it is
Python that finds itself in this unholy mess, while wild-eyed TIMTOWTDI Perl
hums along with CPAN. I can count with the fingers of one hand (and have a
few left over) the number of Perl packages that I use that were not
downloaded from CPAN. In contrast, tons of my Python modules come from
random places: SourceForge, Google Code, github, individual authors'
websites, you name it. How is this possible? Whatever happened to Python's
"There should be one-- and preferably only one --obvious way to do it"???)
So, let's start from the beginning and we can help you though.
Your patience puts me to shame. Thank you for the offer. I suppose that I
should first clean the slate, and re-install everything? Is there clean way
to do this?
~kj

On Thu, Nov 18, 2010 at 4:11 PM, Kynn Jones <ky...@gm...> wrote:
> On Wed, Nov 17, 2010 at 6:33 PM, Benjamin Root <ben...@ou...> wrote:
>
>> As an additional note, if you are having difficulty compiling for MacOS X,
>> why not just ask for help with that?
>
> Just to keep from ranting like a lunatic, basically. The experience was
> traumatic enough to shake my faith in Python altogether, and made me miss
> good ol' CPAN.
> To summarize 2-3 day's worth of frustration:
Yes, installing these GUIs on OSX is a mess, particularly GTK. I only
recommend it for the very brave and foolish. If you use the enthought
python distribution for OSX, you should get a working tkagg, qt4agg,
wxagg and macosx (I think)
http://www.enthought.com/products/epd.php
JDH

I think we are more asking what tutorials have you read to help install
matplotlib (some are better than others), as well as asking what was the
source of your matplotlib installation. In addition, what version of MacOS
X are you using and if you are using the built-in python interpreater or
installed your own? Did you try the DMG file, or from macports, or from
pypi?
There are a variety of issues depending on your Mac system that needs to be
sorted out to determine the best way to go about installing everything. The
particular sticking point is that Apple supplied their own interperater
rather than the standard python interpreater. Unfortunately, this causes
problems with numpy (and thus matplotlib). There are other pitfalls that
makes things tricky.
Personally, I found using macports to be friendly (although it takes forever
because it builds ATLAS...) on my wife's Snow Leopard (32-bit) computer.
Friedrich Romstedt is working on a new dmg build for numpy and matplotlib, I
believe, and some of use have some school of hard-knocks experience to help
with specific questions.
What we really need is improved documentation for the mac install process.
As for the python packager... tell us something we don't know. I have heard
of some people working on an improved system and is testing it out on numpy,
I believe (again, my memory is hazy here). We all know the difficulties of
the packaging system, that's why we are more than willing to help you out.
So, let's start from the beginning and we can help you though. It is
possible!
Ben Root

On Wed, Nov 17, 2010 at 6:33 PM, Benjamin Root <ben...@ou...> wrote:
As an additional note, if you are having difficulty compiling for MacOS X,
> why not just ask for help with that?
>
Just to keep from ranting like a lunatic, basically. The experience was
traumatic enough to shake my faith in Python altogether, and made me miss
good ol' CPAN.
To summarize 2-3 day's worth of frustration:
1.
GTK, GTKAgg:
ImportError: Gtk* backend requires pygtk to be installed.
GTKCairo:
ImportError: No module named backend_gtkcairo
FltkAgg:
ImportError: No module named fltk
QtAgg:
ImportError: Qt backend requires pyqt to be installed.
Qt4Agg:
ImportError: Warning: formlayout requires PyQt4 >v4.3
WX, WXAgg:
ImportError: Matplotlib backend_wx and backend_wxagg require wxPython >=2.8
2. configuration of pygtk fails:
checking for PYGOBJECT... configure: error: Package requirements
(pygobject-2.0 >= 2.21.3) were not met:
No package 'pygobject-2.0' found
3. configuration of pygobject fails:
checking for PYCAIRO... configure: error: Package requirements (pycairo >=
1.0.2
 ) were not met:
No package 'pycairo' found
4. installation of pycairo fails (after > 6 hours of trying a variety of
approaches); currently, importing cairo produces a fatal error:
% python
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cairo
Fatal Python error: Interpreter not initialized (version mismatch?)
zsh: abort python
By this point, I just gave up on getting any more interactive backends for
matplotlib. (I reiterate that the above is a barebone's summary. There's a
lot that I'm omitting.)
As an aside, I have never in my life seen a worse installation system than
pycairo's. If you have not examined it in detail, please do so before
reacting to my comments. In particular look at the waf file, and the files
it invokes. Also, when you find the latter, do a global search for the
number 1337 to get a whiff pycairo's excremental aroma.
There is no point in choosing Python as one's programming language if this
means that one depends on garbage like pycairo. I think it is unfair to put
unsuspecting users of matplotlib through the ordeal of dealing with
pycairo's installation. (And pygtk's and pygobjects's are not much better.)
 We can't force people to write good Python, but at the very least we should
not propagate bad code. Packages like pycairo, pygtk, and pygobjects are
substandard, and they should be ostracized by the rest of the Python
community until they shape up.
Even putting pycairo aside, the Python package installation system is a
disaster. The problems I've summarized on this page are par for the course
with Python packages. Just getting matplotlib to install (even without most
interactive backends) was also a multi-day nightmare...
You see? I'm ranting like a lunatic. Sorry. I'll stop.
~kj

Hi,
It seems that the autofmt_xdate helper method is broken when twinx is
used. Consider the script below:
-----------------------------------------
import datetime as dt
import numpy as np
import matplotlib.pyplot as plt
from matplotlib.dates import date2num
strt = dt.datetime(2000, 3, 15, 6)
delta = dt.timedelta(hours=6)
date_list = [(strt + i*delta) for i in range(100)]
x = date2num(date_list)
y = np.sin(x)
z = np.cos(x)
fig, ax1 = plt.subplots()
ax1.plot(date_list, y, 'b-')
ax2 = ax1.twinx()
ax2.plot(date_list, z, 'r-')
# using the auto format method doesn't work
fig.autofmt_xdate()
plt.show()
-----------------------------------------
This is because the 'is_last_row' attribute isn't present on ax2 and
len(fig.axes) != 1 when the autofmt_xdate method is called on fig.
The attached patch fixes it for me and still seems to give the
advertised behaviour for single and vertically stacked subplots.
Cheers,
Scott

> As an additional note, if you are having difficulty compiling for 
> MacOS X, why not just ask for help with that?
yup -- there are some issues with which Tk is used by tkInter, but wx 
should be easy -- how have you tried to install?
-Chris