I appreciate the help in trying to understand the configuration systems in MM2 and MM3.
2013-04-11 22:11, Barry Warsaw skrev:
On Apr 11, 2013, at 02:22 PM, Elias Assarsson wrote:
- MM2's configuration file is a Python file which really must be imported in order to get a valid set of values. MM3's configuration file is a stack of .ini-style files. I am trying to find and understand the configuration files so that I know what that that needs to be migrated and to what form. Is the MM2 configuration you refer to mainly Mailman/mm_cfg.py and MM3 configuration files src/mailman/config/* and /src/mailman/<listname>/*? Yes, in a deployed Mailman 2, mm_cfg.py will contain the system configuration settings. These override the settings from Defaults.py so a good way to explore is to use
bin/withlistandimport mm_cfgat the Python prompt. I have had a look through bin/withlist, mm_cfg.py and Defaults.py to get a feel for the format of the configuration. Why is bin/withlist relevant for configuration migration? In that it is way to learn about configuration?In MM3, we use lazr.config, which is essentially a configparser type package that allows for stacks of configurations, with pushing and popping values on this stack.
http://pythonhosted.org/lazr.config/
The src/mailman/config/schema.cfg file is at the bottom of the stack and defines the schema, obviously :). From there, src/mailman/config/mailman.cfg essentially instantiates this schema, providing all the defaults. In the testing environment, src/mailman/testing/testing.cfg gets pushed on top of that (and many tests push and pop micro-overrides). In a deployed system, the site's mailman.cfg is on the top of the stack and so can override anything. There are various places this mailman.cfg file is searched; see src/mailman/core/initialize.py for all the gory details. I have had a quick look at the lazr.config documentation and also checked out mailman.cfg, testing.cfg and initialize.cfg in trying to understand the system.
I guess configuration migration scripts should have tests, e.g. to test if some particular MM2 configuration is migrated to the expected MM3 form. If this is so, what would be an appropriate way to collect a MM2 configuration and the expected MM3 form?
- Elias