I originally posted this to the user's list but got no response there. As I think there's a bug in matplotlib here, I'm re-trying on the development list. Here's what I sent to -users back on Mar 13: I am using matplotlib's object-oriented API to dynamically generate some graphs served by a web site. The web site is built with Django and I have generally followed the cookbook example I found here: http://www.scipy.org/Cookbook/Matplotlib/Django for serving matplotlib figures under Django. Specifically my code looks like this: from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas from matplotlib.figure import Figure def generate_png(request, f, year, cid, pid, ic): # ...snipped code that generates the data to graph... fig = Figure() ax = fig.add_subplot(111) ax.set_title(fig_title) ax.set_xlabel("Score") ax.set_ylabel("Frequency") n, bins2, patches = ax.hist(vals, bins, facecolor='blue', edgecolor='blue') if x is not None: patches[x].set_facecolor('red') patches[x].set_edgecolor('red') fig.legend((patches[x],), ('%s (%d)' % (cname, cval),), 'lower left') canvas = FigureCanvas(fig) canvas.print_png(f) # ... snip remainder ... This works fine, except when I run it under a multi-threaded web server (Apache with mod_wsgi in daemon mode with multi-threaded processes) it sometimes (not always) fails with this traceback: File "/home/kmt/django/Django-1.1-alpha-1/django/core/handlers/base.py", line 86, in get_response response = callback(request, *callback_args, **callback_kwargs) File "/home/kmt/software/web/xword/acpt/views.py", line 321, in get_png response = generate_png(request, f, year, cid, pid, ic) File "/home/kmt/software/web/xword/acpt/views.py", line 308, in generate_png canvas.print_png(f) File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line 305, in print_png FigureCanvasAgg.draw(self) File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line 261, in draw self.figure.draw(self.renderer) File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 765, in draw legend.draw(renderer) File "/usr/lib/python2.5/site-packages/matplotlib/legend.py", line 215, in draw t.draw(renderer) File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 329, in draw ismath=self.is_math_text(line)) File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line 113, in draw_text self._renderer.draw_text_image(font.get_image(), int(x), int(y) + 1, angle, gc) RuntimeError: You must call .set_text() before .get_image() I'm not at all familiar with the internals (truly I'm barely familiar with the public APIs) of matplotlib but it appears from this exception that internally there's a 'font' object being shared between threads here, such that one thread can come in and change the font state resulting in a subsequent error in a different thread that was also in the middle of using that font object? If I protect that block of code above with a thread lock so that only one thread is allowed in at a time, the problem goes away. For reference I'm using the latest matplotlib available in the Ubuntu Intrepid (8.10) repositories, which looks to be 0.98.3. In a brief scan I didn't see anything relevant listed in the "what's new" page for 0.98.4 (and can't find a "what's new in 0.98.5" on the matplotlib web site though that is what is listed as most recent?). Nor can I find anything that looks similar logged as a bug in the tracker. Is there something (besides bracketing all access to the matplotlib code with a thread mutex) that I should be doing to make my use of matplotlib thread safe or does it seem like there's a multi-threading bug in matplotlib here? Apologies if this is the wrong list and there is in fact something I ought to be doing in my code (other than using a mutex) to prevent this -- I haven't been able to find anything. My impression from various doc I've read is the object-oriented API is supposed to be thread-safe. Is that true? If so should I file a ticket for this? Thanks for any feedback, Karen
Karen Tracey wrote: > I originally posted this to the user's list but got no response there. > As I think there's a bug in matplotlib here, I'm re-trying on the > development list. Here's what I sent to -users back on Mar 13: Karen, (I saw your question to the users group, and was hoping someone more knowledgeable than myself about threading problems would reply to you.) http://www.mail-archive.com/mat...@li.../msg06152.html I don't think there has been any progress on this question since it came up a year ago in the above thread. Evidently it is something that needs more attention. I would say that you have found a bug, and there are probably many more. There are global objects outside the pyplot interface; maybe they provide opportunities for threads to trip over each other. A reasonable goal would be to have matplotlib be thread-safe at least when the pure OO interface is used, and possibly with some additional restrictions such as "don't mess with rcParams when more than one thread might be running". I suspect this will take some time and effort to achieve--and I don't know who might be able to put in that time and effort. What might help would be a simple but brutal testing framework, independent of web servers etc., that would be likely to make mpl fail quickly unless it really is thread-safe. Maybe you can provide such a test program? And if you are willing to dive into mpl internals and come up with solutions for thread problems, that's even better. For your immediate needs, I suggest that you use only the OO interface (which means that you won't import pylab or pyplot, and so won't use the figure() function), and/or use a mutex as you describe below. (I don't think that dumping "figure" in itself will help with the problem you have run into so far; you will still need the mutex. And if the mutex locks all your plotting, then you probably won't hit any other mpl threading problems.) If you do keep using the figure() function (or any related aspect of the pyplot interface) then be sure to explicitly close each figure. Otherwise your process will chew up all available memory. Eric > > I am using matplotlib's object-oriented API to dynamically generate some > graphs served by a web site. The web site is built with Django and I > have generally followed the cookbook example I found here: > http://www.scipy.org/Cookbook/Matplotlib/Django for serving matplotlib > figures under Django. Specifically my code looks like this: > > from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas > from matplotlib.figure import Figure > > def generate_png(request, f, year, cid, pid, ic): > > # ...snipped code that generates the data to graph... > > fig = Figure() > ax = fig.add_subplot(111) > ax.set_title(fig_title) > ax.set_xlabel("Score") > ax.set_ylabel("Frequency") > n, bins2, patches = ax.hist(vals, bins, facecolor='blue', > edgecolor='blue') > if x is not None: > patches[x].set_facecolor('red') > patches[x].set_edgecolor('red') > fig.legend((patches[x],), ('%s (%d)' % (cname, cval),), 'lower > left') > canvas = FigureCanvas(fig) > canvas.print_png(f) > > # ... snip remainder ... > > This works fine, except when I run it under a multi-threaded web server > (Apache with mod_wsgi in daemon mode with multi-threaded processes) it > sometimes (not always) fails with this traceback: > > File > "/home/kmt/django/Django-1.1-alpha-1/django/core/handlers/base.py", line > 86, in get_response > response = callback(request, *callback_args, **callback_kwargs) > File "/home/kmt/software/web/xword/acpt/views.py", line 321, in get_png > response = generate_png(request, f, year, cid, pid, ic) > File "/home/kmt/software/web/xword/acpt/views.py", line 308, in > generate_png > canvas.print_png(f) > File > "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", > line 305, in print_png > FigureCanvasAgg.draw(self) > File > "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", > line 261, in draw > self.figure.draw(self.renderer) > File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 765, > in draw > legend.draw(renderer) > File "/usr/lib/python2.5/site-packages/matplotlib/legend.py", line 215, > in draw > t.draw(renderer) > File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 329, > in draw > ismath=self.is_math_text(line)) > File > "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", > line 113, in draw_text > self._renderer.draw_text_image(font.get_image(), int(x), int(y) + 1, > angle, gc) > RuntimeError: You must call .set_text() before .get_image() > > I'm not at all familiar with the internals (truly I'm barely familiar > with the public APIs) of matplotlib but it appears from this exception > that internally there's a 'font' object being shared between threads > here, such that one thread can come in and change the font state > resulting in a subsequent error in a different thread that was also in > the middle of using that font object? If I protect that block of code > above with a thread lock so that only one thread is allowed in at a > time, the problem goes away. > > For reference I'm using the latest matplotlib available in the Ubuntu > Intrepid (8.10) repositories, which looks to be 0.98.3. In a brief scan > I didn't see anything relevant listed in the "what's new" page for > 0.98.4 (and can't find a "what's new in 0.98.5" on the matplotlib web > site though that is what is listed as most recent?). Nor can I find > anything that looks similar logged as a bug in the tracker. > > Is there something (besides bracketing all access to the matplotlib code > with a thread mutex) that I should be doing to make my use of matplotlib > thread safe or does it seem like there's a multi-threading bug in > matplotlib here? > > Apologies if this is the wrong list and there is in fact something I > ought to be doing in my code (other than using a mutex) to prevent this > -- I haven't been able to find anything. My impression from various doc > I've read is the object-oriented API is supposed to be thread-safe. Is > that true? If so should I file a ticket for this? > > Thanks for any feedback, > Karen > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
On Thu, Mar 26, 2009 at 8:10 PM, Eric Firing <ef...@ha...> wrote: > Karen Tracey wrote: > > I originally posted this to the user's list but got no response there. > > As I think there's a bug in matplotlib here, I'm re-trying on the > > development list. Here's what I sent to -users back on Mar 13: > > > > Karen, > > (I saw your question to the users group, and was hoping someone more > knowledgeable than myself about threading problems would reply to you.) > > > http://www.mail-archive.com/mat...@li.../msg06152.html > > I don't think there has been any progress on this question since it came > up a year ago in the above thread. Evidently it is something that needs > more attention. I would say that you have found a bug, and there are > probably many more. There are global objects outside the pyplot > interface; maybe they provide opportunities for threads to trip over > each other. A reasonable goal would be to have matplotlib be thread-safe > at least when the pure OO interface is used, and possibly with some > additional restrictions such as "don't mess with rcParams when more than > one thread might be running". It might not be too much trouble to protect RcParams and its data, although I dont know how disruptive it would be to the mpl codebase and to users for rcParams to begin returning copies of things like font lists. Darren
On Fri, Mar 27, 2009 at 5:54 AM, Darren Dale <dsd...@gm...> wrote:
>
> It might not be too much trouble to protect RcParams and its data, although
> I dont know how disruptive it would be to the mpl codebase and to users for
> rcParams to begin returning copies of things like font lists.
>
In addition to the rc params, I suspect some of the caching we do at the
module level, eg in agg
class RendererAgg(RendererBase):
texd = maxdict(50) # a cache of tex image rasters
_fontd = maxdict(50)
might be what is hurting here. Karen, could you try editing
site-packages/matplotlib/backends/backend_agg.py and moving these two lines
into the __init__method so they are at the instance level rather than the
class level. Eg,
def __init__(self, width, height, dpi):
if __debug__: verbose.report('RendererAgg.__init__',
'debug-annoying')
RendererBase.__init__(self)
self.texd = maxdict(50) # a cache of tex image rasters
self._fontd = maxdict(50)
and see if that helps. Also, make sure you have disabled usetex in
matplotlibrc, since the use of the filesystem for caching the tex datafiles
is probably not thread safe. My guess is that the font cache on the file
system is not thread safe either, but this may only affect the first run of
mpl after a clean install.
Also, as Eric suggests, a freestanding script which is thread enabled
(preferably just using mpl and the standard threading library rather than
django et al) which uses the agg backend that we could use for debugging
would be very helpful.
JDH
Thanks for the responses everyone. More below inline...
On Fri, Mar 27, 2009 at 9:12 AM, John Hunter <jd...@gm...> wrote:
> On Fri, Mar 27, 2009 at 5:54 AM, Darren Dale <dsd...@gm...> wrote:
>
>>
>> It might not be too much trouble to protect RcParams and its data,
>> although I dont know how disruptive it would be to the mpl codebase and to
>> users for rcParams to begin returning copies of things like font lists.
>>
>
>
> In addition to the rc params, I suspect some of the caching we do at the
> module level, eg in agg
>
>
> class RendererAgg(RendererBase):
>
> texd = maxdict(50) # a cache of tex image rasters
> _fontd = maxdict(50)
>
> might be what is hurting here. Karen, could you try editing
> site-packages/matplotlib/backends/backend_agg.py and moving these two lines
> into the __init__method so they are at the instance level rather than the
> class level. Eg,
>
> def __init__(self, width, height, dpi):
> if __debug__: verbose.report('RendererAgg.__init__',
> 'debug-annoying')
> RendererBase.__init__(self)
> self.texd = maxdict(50) # a cache of tex image rasters
> self._fontd = maxdict(50)
>
> and see if that helps.
Yes, this change appears to fix the problem. I created a standalone script
to recreate the problem. The script starts several threads. Each thread
enters a loop generating a (different) png file. With the original
matplotlib code, the threads seem unable to complete 50 iterations without
the exception being raised. (I tried the script at least a dozen times, it
never finished successfully with 50 iterations. Usually failed before 5,
but once made it as high as 20, so I bumped it up to 50 and that seemed to
ensure it would fail before finishing). With the above change to make the
texd and _fontd caches per-instance, the script has finished successfully 4
times. Seems pretty convincing evidence that it fixes the problem.
>
Also, make sure you have disabled usetex in matplotlibrc, since the use of
> the filesystem for caching the tex datafiles is probably not thread safe.
> My guess is that the font cache on the file system is not thread safe
> either, but this may only affect the first run of mpl after a clean install.
>
Not sure what matplotlibrc is? I found a file
/usr/share/matplotlib/matplotlib.conf that has usetex set to False. Is that
it? If so I guess it's been disabled all along, this is not something I
have fiddled with.
> Also, as Eric suggests, a freestanding script which is thread enabled
> (preferably just using mpl and the standard threading library rather than
> django et al) which uses the agg backend that we could use for debugging
> would be very helpful.
>
Understood, and I did make a standalone script (plus a set of pickle files
for the data to graph) to recreate it. I can zip them up and send them
somewhere, or open a ticket and attach it there, or whatever. Let me know
what would be most convenient/helpful.
Thanks!
Karen
On Fri, Mar 27, 2009 at 1:23 PM, Karen Tracey <kmt...@gm...> wrote: > > Yes, this change appears to fix the problem. I created a standalone script > to recreate the problem. The script starts several threads. Each thread > enters a loop generating a (different) png file. With the original > matplotlib code, the threads seem unable to complete 50 iterations without > the exception being raised. (I tried the script at least a dozen times, it > never finished successfully with 50 iterations. Usually failed before 5, > but once made it as high as 20, so I bumped it up to 50 and that seemed to > ensure it would fail before finishing). With the above change to make the > texd and _fontd caches per-instance, the script has finished successfully 4 > times. Seems pretty convincing evidence that it fixes the problem. > OK, I made this change to svn r7008. We probably do not gain *that much* by caching across renderers anyhow. > > > Also, make sure you have disabled usetex in matplotlibrc, since the use of >> the filesystem for caching the tex datafiles is probably not thread safe. >> My guess is that the font cache on the file system is not thread safe >> either, but this may only affect the first run of mpl after a clean install. >> > > Not sure what matplotlibrc is? I found a file > /usr/share/matplotlib/matplotlib.conf that has usetex set to False. Is that > it? If so I guess it's been disabled all along, this is not something I > have fiddled with. > matplotlib.conf is an experimental config that is no longer in use (but it won't hurt you to have it lying around). See http://matplotlib.sourceforge.net/users/customizing.html for details on the matplotlibrc file > > Understood, and I did make a standalone script (plus a set of pickle files > for the data to graph) to recreate it. I can zip them up and send them > somewhere, or open a ticket and attach it there, or whatever. Let me know > what would be most convenient/helpful. > No need for data files -- just use np.random.rand to make up some random data for plotting. That keeps things simple and small, and you can post the script to the list, and hopefully we can find a home for it in our unit tests. Thanks, JDH
On Fri, Mar 27, 2009 at 5:11 PM, John Hunter <jd...@gm...> wrote: > On Fri, Mar 27, 2009 at 1:23 PM, Karen Tracey <kmt...@gm...> wrote: > >> With the above change to make the texd and _fontd caches per-instance, the >> script has finished successfully 4 times. Seems pretty convincing evidence >> that it fixes the problem. >> > > OK, I made this change to svn r7008. We probably do not gain *that much* > by caching across renderers anyhow. > > Cool, thanks! > >> >> Also, make sure you have disabled usetex in matplotlibrc, since the use of >>> the filesystem for caching the tex datafiles is probably not thread safe. >>> My guess is that the font cache on the file system is not thread safe >>> either, but this may only affect the first run of mpl after a clean install. >>> >> >> Not sure what matplotlibrc is? I found a file >> /usr/share/matplotlib/matplotlib.conf that has usetex set to False. Is that >> it? If so I guess it's been disabled all along, this is not something I >> have fiddled with. >> > > matplotlib.conf is an experimental config that is no longer in use (but it > won't hurt you to have it lying around). See > http://matplotlib.sourceforge.net/users/customizing.html for details on > the matplotlibrc file > Hmm, the Ubuntu packaging for matplotlib seems to put a copy of matplotlibrc only in /etc, where, I gather, it will not ever be used by matplotlib? I guess one is supposed to copy it to one's home directory and do per-user customization there. For my case, where the code is running under Apache, I'd guess no matplotlibrc is being found so all defaults are being used. > > No need for data files -- just use np.random.rand to make up some random > data for plotting. That keeps things simple and small, and you can post the > script to the list, and hopefully we can find a home for it in our unit > tests. > OK, I reduced it to a bare minimum, using random data. I removed stuff that was in my code like customizing colors, highlighting a particular bar, and even setting of the title and axis labels since it turns out none of that is necessary to trip the exception. I'll append below a script that reliably reproduces the error on my machine. 8 threads at 50 iterations seems sure to hit it, fewer threads or fewer iterations may not. Hope this is helpful, Karen #! /usr/bin/python import os import threading import traceback import numpy as np from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas from matplotlib.figure import Figure thread_count = 8 max_iterations = 50 exception_raised = False def png_thread(tn): png_fname = 'out%d.png' % tn vals = 100 + 15 * np.random.randn(10000) i = 0 excp = None global exception_raised while not exception_raised and i < max_iterations: i += 1 png_f = open(png_fname, 'wb') try: fig = Figure() ax = fig.add_subplot(111) ax.hist(vals, 50) FigureCanvas(fig).print_png(png_f) except Exception, excp: pass png_f.close() if excp: print 'png_thread %d failed on iteration %d:' % (tn, i) print traceback.format_exc(excp) exception_raised = True else: print 'png_thread %d completed iteration %d.' % (tn, i) os.unlink(png_fname) def main(tc): threads = [] for i in range(tc): threads.append(threading.Thread(target=png_thread, args=(i+1,))) for t in threads: t.start() for t in threads: t.join() if not exception_raised: msg = 'Success! %d threads completed %d iterations with no exceptions raised.' else: msg = 'Failed! Exception raised before %d threads completed %d iterations.' print msg % (tc, max_iterations) if __name__== "__main__": main(thread_count)
Karen Tracey wrote: > Hmm, the Ubuntu packaging for matplotlib seems to put a copy of > matplotlibrc only in /etc, where, I gather, it will not ever be used by > matplotlib? I guess one is supposed to copy it to one's home directory > and do per-user customization there. For my case, where the code is > running under Apache, I'd guess no matplotlibrc is being found so all > defaults are being used. Karen, That seems a little odd; matplotlib doesn't look in /etc by default. Although I run ubuntu, I have never used the ubuntu package, so I have not run into this. The default matplotlibrc has been stripped down to a bare minimum: everything but the default backend selection is commented out. You may have already discovered this, but in case you haven't, you can find out where the active matplotlibrc is being found by using matplotlib_fname(): In [1]:import matplotlib In [2]:matplotlib.matplotlib_fname() Out[2]:'/usr/local/lib/python2.5/site-packages/matplotlib/mpl-data/matplotlibrc' The docstring explains the search order: Return the path to the rc file Search order: * current working dir * environ var MATPLOTLIBRC * HOME/.matplotlib/matplotlibrc * MATPLOTLIBDATA/matplotlibrc Thank you for the test script. I have added it to the "unit" subdirectory of matplotlib, after adding a short docstring. JDH may want to modify or move it. Eric
On Sat, Mar 28, 2009 at 11:45 PM, Eric Firing <ef...@ha...> wrote:
> Karen Tracey wrote:
>
> Hmm, the Ubuntu packaging for matplotlib seems to put a copy of
>> matplotlibrc only in /etc, where, I gather, it will not ever be used by
>> matplotlib? I guess one is supposed to copy it to one's home directory and
>> do per-user customization there. For my case, where the code is running
>> under Apache, I'd guess no matplotlibrc is being found so all defaults are
>> being used.
>>
>
> Karen,
>
> That seems a little odd; matplotlib doesn't look in /etc by default.
> Although I run ubuntu, I have never used the ubuntu package, so I have not
> run into this.
>
> The default matplotlibrc has been stripped down to a bare minimum:
> everything but the default backend selection is commented out.
>
> You may have already discovered this, but in case you haven't, you can find
> out where the active matplotlibrc is being found by using
> matplotlib_fname():
>
> In [1]:import matplotlib
>
> In [2]:matplotlib.matplotlib_fname()
>
> Out[2]:'/usr/local/lib/python2.5/site-packages/matplotlib/mpl-data/matplotlibrc'
>
Thanks, I hadn't found that. It seems the Ubuntu packaging has changed
things a bit:
kmt@lbox:~$ python
Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib
>>> matplotlib.__version__
'0.98.3'
>>> matplotlib.matplotlib_fname()
'/etc/matplotlibrc'
>>> matplotlib.get_data_path()
'/usr/share/matplotlib/mpl-data'
>>>
Looking at the source code, I see in
/usr/lib/python2.5/site-packages/matplotlib/__init__.py (which is actually a
link to /usr/share/pyshared/matplotlib/__init__.py which I gather is a way
of having packages that run under multiple Python versions only have one
copy of the files installed), in matplotlib_fname, the very end is:
path = '/etc' # guaranteed to exist or raise
fname = os.path.join(path, 'matplotlibrc')
if not os.path.exists(fname):
warnings.warn('Could not find matplotlibrc; using defaults')
return fname
That is, it looks like they have hardcoded '/etc' where the
lib/matplotlib/__init__.py file in SVN has a call to get_data_path(). Don't
know why, but apparently if you run the Ubuntu repository version it's
/etc/matplotlibrc that gets used (assuming nothing is found earlier in the
search order). They like all config-type files to be under /etc maybe?
>
Thank you for the test script. I have added it to the "unit" subdirectory
> of matplotlib, after adding a short docstring. JDH may want to modify or
> move it.
>
>
You're welcome. Hope it's useful. I am glad the fix was relatively
simple.
Karen
On Sun, Mar 29, 2009 at 1:14 AM, Karen Tracey <kmt...@gm...> wrote:
> On Sat, Mar 28, 2009 at 11:45 PM, Eric Firing <ef...@ha...> wrote:
>
>> Karen Tracey wrote:
>>
>> Hmm, the Ubuntu packaging for matplotlib seems to put a copy of
>>> matplotlibrc only in /etc, where, I gather, it will not ever be used by
>>> matplotlib? I guess one is supposed to copy it to one's home directory and
>>> do per-user customization there. For my case, where the code is running
>>> under Apache, I'd guess no matplotlibrc is being found so all defaults are
>>> being used.
>>>
>>
>> Karen,
>>
>> That seems a little odd; matplotlib doesn't look in /etc by default.
>> Although I run ubuntu, I have never used the ubuntu package, so I have not
>> run into this.
>>
>> The default matplotlibrc has been stripped down to a bare minimum:
>> everything but the default backend selection is commented out.
>>
>> You may have already discovered this, but in case you haven't, you can
>> find out where the active matplotlibrc is being found by using
>> matplotlib_fname():
>>
>> In [1]:import matplotlib
>>
>> In [2]:matplotlib.matplotlib_fname()
>>
>> Out[2]:'/usr/local/lib/python2.5/site-packages/matplotlib/mpl-data/matplotlibrc'
>>
>
> Thanks, I hadn't found that. It seems the Ubuntu packaging has changed
> things a bit:
>
> kmt@lbox:~$ python
> Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
> [GCC 4.3.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import matplotlib
> >>> matplotlib.__version__
> '0.98.3'
> >>> matplotlib.matplotlib_fname()
> '/etc/matplotlibrc'
> >>> matplotlib.get_data_path()
> '/usr/share/matplotlib/mpl-data'
> >>>
>
> Looking at the source code, I see in
> /usr/lib/python2.5/site-packages/matplotlib/__init__.py (which is actually a
> link to /usr/share/pyshared/matplotlib/__init__.py which I gather is a way
> of having packages that run under multiple Python versions only have one
> copy of the files installed), in matplotlib_fname, the very end is:
>
> path = '/etc' # guaranteed to exist or raise
> fname = os.path.join(path, 'matplotlibrc')
> if not os.path.exists(fname):
> warnings.warn('Could not find matplotlibrc; using defaults')
> return fname
>
> That is, it looks like they have hardcoded '/etc' where the
> lib/matplotlib/__init__.py file in SVN has a call to get_data_path(). Don't
> know why, but apparently if you run the Ubuntu repository version it's
> /etc/matplotlibrc that gets used (assuming nothing is found earlier in the
> search order). They like all config-type files to be under /etc maybe?
>
They are trying to do right by the linux file standard. /etc is really where
the global matplotlibrc belongs.
Darren