I recently run into a problem with the .matplotlib directory. I run a script as a daemon, that in its turn runs several scripts to create graphs (often the same script with different input parameters), dependent on an outside trigger. Recently, I found that these script crashed with an OSError during the 'import matplotlib' phase, at the point where it tries to check that the .matplotlib directory is writeable. The exact traceback is appended below.
Searching on the mailing list, I found someone had the same problem almost a year ago ( http://sourceforge.net/mailarchive/message.php?msg_id=44964AD1.605%40yahoo.com ), but it appears that that post doesn't have a response.
A wider search resulted in this post, http://osdir.com/ml/python.peak/2006-06/msg00019.html , where the response suggests these problems are caused by all the things mpl does in its __init__ file.
A few notes on my setup:
- the .matplotlib is a symbolic link to a .python/matplotlib directory, since I'd like to keep my python resources together (eg, .python also contains an ipython directory). I've currently changed the symlink to a proper directory, but haven't had a chance to test this new setup. Anyway, afaik, symlinks should work properly
- the scripts that are run from the daemon script, are run in the background, and quite often shortly after each other. Whether that creates a deadlock situation or something, I don't know. Obviously, I'm using a non-interactive backend, agg in this case.
- the problem only showed after I upgraded from mpl version 0.87 to 0.9.
- interactively, everything runs fine.
- everything runs under a locally installed python, which is called with the appropriate path from the script
- python version 2.4.4, numpy version 1.0
Does anyone have a suggestion what went wrong, and how to properly fix all this? As a temporary measure, I now ignore the _is_writeable(p) result in __init__.py (the directory, and therefore the symlink, were/are writeable when this occurred, as far as I can tell).
I like mpl very much, but this problem may render it much less usable for me; a temporary fix would be fine for now, but it actually feels like a bug to me.
Thanks a lot,
full traceback (note: replaced directories with ~)
Traceback (most recent call last):
File "~/myscript.py", line 64, in ?
File "~/myscript.py", line 59, in main
File "~/myscript.py", line 27, in run
sigmaclip=parser['sigmaclip'], invert=True, compass=True)
File "~/python/modules/fitsimage/FITSImage_numpy.py", line 777, in plot
import matplotlib as mpl
File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py", line 1019, in ?
rcParams = rc_params()
File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py", line 976, in rc_params
fname = matplotlib_fname()
File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py", line 922, in matplotlib_fname
fname = os.path.join(get_configdir(), 'matplotlibrc')
File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py", line 273, in wrapper
ret = func(*args, **kwargs)
File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py", line 329, in _get_configdir
OSError: [Errno 17] File exists: '<...>/.matplotlib'