On Tuesday 24 July 2007 5:49:27 pm Fernando Perez wrote: > On 7/24/07, Darren Dale <[EMAIL PROTECTED]> wrote: > > creating RecursiveConfManager with no_mplrc.conf, which does not exist > > calling RecursiveConfigManagers write() method > > Here are the contents of no_mplrc.conf: > > > > > > I might have expected to see the MPLConfig defaults > > Nope. The point is that a top-level file may well start empty, > without even an 'include' statement at all, and as the user changes > things (via the cmd line or edit_traits()), ONLY those changes will be > written in.
Ah! (Smacks self on forehead) > This way, users don't carry a lot of declaration of > internal defaults that may potentially change as MPL evolves; this > minimizes the chances for config errors appearing in the future when > they upgrade. > > > Backend now changed to: Cairo > > calling RecursiveConfigManagers write() method > > Here are the new contents of no_mplrc.conf: > > > > > > in this test, dsd finds that no_mplrc.conf is empty after both writes > > I suggest that tconfig should either write to the file, or raise an > > error when the file does not exist > > removing no_mplrc.conf > > Fixed. See note on file creation at end. Great! > > ------------------------------------------------------------------------ > > > > moving mplrc.conf to mplrc.conf.off > > copying mplrc2.conf to mplrc2_copy.conf > > loading config from mplrc2_copy.conf, which includes mplrc.conf- > > but mplrc.conf does not exist > > here are the contents of mplrc2_copy.conf, as loaded > > > > # A hierarchical configuration > > include = 'mplrc.conf' > > > > Backend now changed to: Cairo > > writing to file > > Here are the new contents of mplrc2_copy.conf: > > > > # A hierarchical configuration > > include = 'mplrc.conf' > > > > I might have expected to see the backend.use here > > maybe an error should be raised when a config file includes another > > config file that does not exist > > moving mplrc.conf.off to mplrc.conf, deleting mplrc2_copy.conf > > Fixed, now raises IOError. Great! > I implemented this policy: > > 1. Creating a TConfigManager(FooConfig,'missingfile.conf') will work > fine, and 'missingfile.conf' will be created empty. > > 2. Creating TCM(C,'OKfile.conf') where OKfile.conf has > > include = 'missingfile.conf' > > conks out with IOError. > > My rationale is that creating top-level empty files is a common and > reasonable need, but that having invalid include statements should > raise an error right away, so people know immediately that their files > have gone stale. > > It seems to me that this system does everything John and I discussed > over the phone on Sat, and that others have mentioned here. > Basically, MPL could install at startup time a simple matplotlib.conf > file that reads: > > # MPL config file. For configuration details, try exloring > # pylab.rc > # If you are using WX or IPython with -wthread, you can try > # pylab.rc.edit_traits() > # for a GUI. > # This file: > # /path/to/full/copy/of/mpl/internal/mpl.conf > # is an auto-generated file with the complete current internal defaults. > # Feel free to copy pieces you need from it if you prefer. > # Note that you can create hierarchies of config files by using > # include = '/path/to/base.conf' > # For more details on MPL's config system, see > # http://matplotlib.sf.net/great/information/page.html > > ### EOF > > That's it. Exactly zero actual data in the default file, just some > information to get people going. This file will only grow what people > actually change, thus minimizing the chances for problems that pop > like dandelions as upgrades happen. > > In addition, even users who don't run with WX* backends could always > just start ipython -wthread to tweak their config, save it, and then > go back to using whatever they normally work with in production. WX > would only be needed for the traits GUI to open, not for any of MPL > itself. > > Comments, feedback? Thank you for all you have already done, Fernando. I tried adding a bogus key to mplrc.conf (top level, bogus = 1), and ran the mpltest.py script from IPython. The result is posted at the end of this message. Would it be possible to provide some more context for bad sections or keys? Like the section in which the key is located, the line number, or a list of acceptable keys for that section? I think it will be necessary for the error to relay the absolute path and file that failed, especially with nested configs. We could catch that error, and point to the default conf that ships with matplotlib, but a little additional information from tconfig would be helpful. It might be nice to be able to deprecate keys as matplotlib or ipython evolves. Even with our current system, when we give a helpful message that a key is no longer valid, we will sometimes get questions on the mailing lists asking how to fix the problem. Raising an error for unrecognized keys might be too extreme. Maybe TConfig should have a raiseOnKeyError option, so that bad values can be reported with a warning instead, and the end user can get up and running without fixing it right away. Darren <class 'tconfig.TConfigInvalidKeyError'> Traceback (most recent call last) /home/darren/src/ipython1/sandbox/tconfig/mpltest.py in <module>() 10 11 mconf = 'mplrc.conf' ---> 12 mplconf = TConfigManager(MPLConfig, mconf, filePriority=True) 13 mplconf.tconf.backend.use = 'Qt4Agg' 14 mplconf.write() /home/darren/src/ipython1/sandbox/tconfig/tconfig.py in __init__(self, configClass, configFilename, filePriority) 539 540 if filePriority: --> 541 self.tconf = configClass(self.fconfCombined,monitor=monitor) 542 else: 543 # Push defaults onto file object /home/darren/src/ipython1/sandbox/tconfig/tconfig.py in __init__(self, config, parent, monitor) 369 invalid_scalars = cf_scalars - my_scalars 370 if invalid_scalars: --> 371 raise TConfigInvalidKeyError("Invalid keys: %s" % invalid_scalars) 372 373 # ... and sections <class 'tconfig.TConfigInvalidKeyError'>: Invalid keys: set(['bogus']) WARNING: Failure executing file: <mpltest.py> ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
