In article <4CC...@no...>, Christopher Barker <Chr...@no...> wrote: > On 10/25/10 1:41 PM, Daniel Hyams wrote: > > It doesn't really insist on it right? There are MATPLOTLIBDIR and > > MPLCONFIGDIR environment variables. > > > You can set these env variables within your code, before import of > > matplotlib via os.environment. > > I'm glad I've learned about this, and will start doing it with my > bundled up apps -- but that does seem pretty un-pythonic -- shouldn't it > be possible to set this sort of thing without resorting to that little > round trip through environment variables? > > Not a big deal, but it feels kludgy. > > -Chris It's an interesting question. You can't call a matplotlib function to do it because it has to happen before matplotlib is loaded. I suppose there could be a configuration package to perform the operation. Having looked into it some, I confess I am not that sold on using MPLCONFIGDIR in my bundled applications. Issues include: * The font cache uses absolute paths. Thus the cache will break if the application is moved or renamed. So there is no point to using MPLCONFIGDIR to avoid the problem of matplotlib crashing when the font cache is out of date. It cannot help! * Where to put it? I had hoped to put it in the bundled application itself, so that it would be thrown out when the application was thrown out. But matplotlib crashes if the directory cannot be written (pity that; it'd be nice if it could run without a font cache). Thus the application could not be run from the disk image or from an Applications directory that an admin had protected by making it read-only. I'd like to avoid generating a new MPLCONFIGDIR directory for every version of my application (or every version of matplotlib). So it seems to me the only sensible choice is to have one MPLCONFIGDIR shared by all versions of the application. The only point I can see to doing this is to avoid user-written matplotlibrc files: the danger that they would mess up the appearance of the application or be incompatible with the version of matplotlib in the application. An alternative is to just keep using the default MPLCONFIGDIR (~/.matplotlib) and put up with the risk of a matplotlibrc file doing bad things. That's my plan for now since I know few users who bother to set exotic things in their matplotlibrc files, and my application already explicitly set the important settings. -- Russell