On Thu, Jan 29, 2009 at 5:49 PM, William Stein <wst...@gmail.com> wrote: > > On Wed, Jan 28, 2009 at 10:07 PM, Jason Grout > <jason-s...@creativetrax.com> wrote: >> >> I just finished upgrading the matplotlib spkg to the newest version. >> See http://trac.sagemath.org/sage_trac/ticket/4774 >> >> This version of matplotlib deprecates some of the constructs found in >> Sage's matplotlibrc (which is located in $SAGE_ROOT and automatically >> copied to $DOT_SAGE if needed every time sage starts up). The result is >> a bunch of deprecation warnings every time Sage starts up (when >> matplotlib loads Sage's matplotlibrc file). In trying to figure out >> what to do about this with several other developers, one option that >> came up was just throwing away/ignoring the special Sage matplotlibrc >> and using the normal, standard defaults for matplotlibrc (including the >> standard location for a customized matplotlibrc). >> >> In investigating things more deeply, there were only a few real changes >> we made to the default behavior of matplotlib. IIRC, a few font choices >> were reordered, legends were changed to display a bit more of the >> function, and the dpi of saved images was bumped up from 80 dpi to 100 >> dpi (but this should be set when Sage saves an image anyway, so I don't >> know that this changes anything). >> >> So here's a proposal: Should Sage stop distributing a custom >> matplotlibrc, and ignore matplotlibrc files that already exist in the >> $DOT_SAGE directories? >> >> Note that if people really want to customize the matplotlib settings, >> they can always use the standard location for matplotlibrc (i.e., >> ~/.matplotlib/matplotlibrc, I think). This will clean code out of the >> bin repository and reduce startup time for sage as well. Patches which >> do this are posted to #4774. >> >> I vote yes, provided some sort of note is made in the release notes >> about the ignored matplotlibrc file. > > I vote no, since I created the $DOT_SAGE/matplotlib directory > *precisely* because of problems that happen if you were to do what you > describe above. For starters, people often also used a system-wide > Python with their own version of matplotlib -- then end result was > that if they tried to switch back and forth between sage and > python/ipython/matplotlib, they would get tons of deprecation > warnings, since the systemwide version of matplotlib is often > different than the sage version. > > Second, how will what you suggest solve any problems? All you do is > move the problem from $DOT_SAGE/matplotlib/matplotlibc to > $HOME/.matplotlibrc. It's exactly the same problem. You just > temporarily put it off for a while. > > I *wish* matplotlib would replace their stupid deprecation warnings by > something that just updates the matplotlibrc file, and say makes a > copy of the old one. Is there any way we could catch the warnings and > if they occur move $DOT_SAGE/matplotlib/matplotlibrc to another file, > then put a new matplotlibrc in place and print a message that this > just happened? You could do that by making slightly patching > matplotlib as well. I think matplotlib's behavior of emitting > warnings but doing nothing helpful to resolve them is just obnoxious.
Maybe matplotlib developers would accept a patch fixing this. Ondrej ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
