Am 24.02.2010 um 00:22 schrieb Carl Meyer: > Hey all, > > As my first post on pinax-core-dev ;-) I'd like to propose that Pinax > adopt Transifex' split settings solution. [1] It's flexible, it's > conceptually simple, and it solves many of the problems inherent in > import-based split-settings solutions. > > The pattern is familiar from e.g. a Debian-based installation of > Apache (or many other projects), which has a conf.d/ directory > containing a list of configuration files like 05_something.conf, > 10_something_else.conf, etc: the files are loaded in order (initial > number provides predictable lexicographic ordering) and each > configuration file is free to add to, modify or tweak the > configuration provided from previous files. > > For Pinax, this would look like a top-level conf/ directory containing > something like 05_base.py, 10_pinax.py, etc (or whatever they might > be). The actual settings module itself becomes a simple wrapper that > lists the contents of the conf/ directory, orders them, and calls > execfile(fn) on each one in turn; or exec(open(fn).read()) to be > forward-thinking, since execfile has been removed in Python 3. > > Because the code from each conf/ file is executed in the same local > namespace, each conf file is able to see and modify all of the > settings from the previous files, which allows plenty of flexibility > in appending to or tweaking settings like MIDDLEWARE_CLASSES, the new > DATABASES, etc. > > It also makes it easy to use various systems for deployment-specific > settings: a VCS-ignored 90_local.py file (which doesn't even need to > exist), or a sub-directory of host-specific conf files, one of which > can be symlinked into the conf/ directory on a given deployment. > > It's also trivial to provide a 99_lazy.py file which can contain > "lazy" settings, whose value ought to be based on the value of some > other setting, which may be modified by other settings file (including > a deployment-specific file). > > The implementation of this is quite simple, but I do have it > implemented for all my projects and would be happy to contribute the > implementation to Pinax if the core devs approve.
For the record, I'm generally +1 on this proposal and have used the concept myself in a few projects outside of Pinax and enjoyed using it when working with Transifex. It requires a little attention in case a project needs to be distributed since the conf files are package data to distutils because if we don't add a ``__init__.py`` to the ``conf/`` dir. A ``recursive-include path/to/conf/*.ext`` in the manifest template of the project (if it exists) suffices. Regarding the file extension, I'm torn between using the ``.conf`` file extension, which might be a source for confusion since it hides the fact that "it's just Python", and ``.conf.py`` which is more verbose but would highlight the fact that it's a non-importable config file and would still conveniently apply Python code highlighting. Jannis -- You received this message because you are subscribed to the Google Groups "Pinax Core Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pinax-core-dev?hl=en.
