Hi John, On Sunday 22 July 2007 9:51:05 am John Hunter wrote: > On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote: > > 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.
I was thinking along these lines as well, having an uncommented "master config" file that ships with mpl. I was thinking of using that file as a template to automatically generate commented out versions, but I like Fernando's recursive include framework much better. > > 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.. They do. > > 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. As long as matplotlib is not designed to take advantage of notification, etc, the existing rc system could provide nearly the same functionality as the traited config system. The validators would have to be significantly improved. We would still have problems arising from having to parse strings, convert values, and then validate. For example, the latex preamble is of limited usefulness. > Recursive includes and > runtime persistence are nice, but noone has ever asked for that as far > as I know. I imagine our more advanced users would find them extremely useful once they knew about them. But imagine trying to explain them in the users guide. > 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. The issue of configuration has come up several times on the mailing lists over the last few years, and Fernando's tconfig feels like the right solution. On the other hand, I can't be too enthusiastic about pushing for inclusion in matplotlib in the near future, because I havent been able to install traits as a separate package. At the moment, the following command easy_install -f http://code.enthought.com/enstaller/eggs/source/unstable "enthought.traits < 3.0a" does not install all the required modules. Running this command: sudo easy_install -f http://code.enthought.com/enstaller/eggs/source/unstable "enthought.etsconfig < 3.0a" "enthought.util <3.0a" "enthought.debug <3.0a" will get you traits, along with debug, developer, envisage, etsconfig, help io, logger, naming, plugins.python_shell, plugins.text_editor, pyface, resource, sweet_pickle, traits.ui.wx, type_manager, and util. Remember that email we got a while back from the guy complaining about the ubuntu package manager installing too many gui toolkits? Hopefully it is in Enthought's best interest to work out the dependency issues. > 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. I agree. I think we could give the new system a trial in svn (when we think it is ready) by wrapping the traited rc object with an object that quacks like an rcParams dict. That way, the new system could be turned on or off so it wouldnt be disruptful to the broader community of svn users. Darren ------------------------------------------------------------------------- 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
