On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote: > Im attaching a patch, it includes lots of changes to mplconfig.py, a realistic > mplrc.conf file (feel free to rename it to mpl.conf or matplotlib.conf or > whatever seems standard), and a backup of that .conf file. The mpltest lets > me try your trick of modifying a well formatted file in place. Very nice!
Hey Darren, I've been following the config discussion, but am not as deep into it as you and Fernando so I'll just make some general comments. > 2) It would be nice to be able to write a default file that has everything > commented out with the exception of backend.use and numerix. We comment out > all the parameters in the current matplotlibrc, which makes it easier to > identify what has been customized during troubleshooting. F and I talked about the "commented out" thing on the phone last night. The motivation for this was: when we upgrade rc we don't want users who have never seen or modified an rc file to get a rc deprecation warning. But Fernando thought it would be impossible to deal intelligently with comment files in the new framework, eg persisted changes would not necessarily be written to the portion where the commented out version was, and the commented part would still be in. We discussed one possibility to install a full, uncommented default config file in the system directory (eg mpl-data) at install time which was guaranteed to be correct, and in the users .matplotlib directory just put a stub which includes that file (so they know where to find it and copy-and-paste from) and in the user file also puy any build time config we detect, eg backend and formerly, numerix. Changes made to the rc object when saved would always go to the top level rc file, eg the one in the user dir. So the user rc would be a pointer to the main rc with local modifications. > 3) Any key appearing in the conf file is validated, so you cant mispell a key > name or accidentally include some garbage. But after generating the MPLConfig > object mplrc, you can do something like mplrc.nonsense = 1 without generating > an error. Is there a way to prevent the creation of additional attributes > once mplrc has been instantiated? That was a useful improvement to our > current rcParams. I believe HasStrictTraits is designed for this. > 4) It would be nice to create a new mpl.conf file based on changes made > interactively, without having to overwrite the old file, yet still preserving > the order and comments seen in the default I attached. Maybe copying the > default into the new location, and using it as the template? Even better, > when I saved a new file, it would preserve the defaults order, and any > settings that are identical to the defaults would be commented out. Ok, I'm > getting carried away. sorry. I don't know if my comments above address this.. > I'm feeling a bit cross-eyed from coding all day, and this is a little too > abstract at the moment for my poor head. Good luck! I know the feeling from my own experience over the last few days. I think we should make sure we know what we are getting with this new config approach, ie what is missing from our current system that people want to do but can't. For mpl1, I don't mind doing something different if it is simply better and cleaner. For matplotlib, I think we need a higher bar, though not an infinitely high one. For the latter, I think it needs to solve an existing problem, and do so in a way that we expect to solve it "for good". I think the system you and Fernando are discussing probably meets the second criteria, since you've obviously put a lot of thought into what a good config system needs. I am less convinced about the first. With your latest changes to the current rc system, we have config time and runtime validation of the keys and values, albeit a homegrown and not terribly elegant version of what traits does more elegantly. Recursive includes and runtime persistence are nice, but noone has ever asked for that as far as I know. For ipython, which is an environment where building hybrids of other environments is a common need, recursive includes are clearly useful. So I'd like to make sure we have a clear rationale here, other than shiny and new. We geeks do like our toys. That said, as part of a general traitification of matplotlib artists, I think it is natural and good to have a traitified rc file. If you view this work as a first step in that direction, I think that is sufficient justification, because having traitified artists will solve a clear and existing need: a generalized validation and notification framework. And the goal of having a common config system across core packages certainly has merits as well. JDH ------------------------------------------------------------------------- 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
