Hi John,
> 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
···
On Sunday 22 July 2007 9:51:05 am John Hunter wrote:
On 7/21/07, Darren Dale <dd55@...143...> wrote: