I've never been completely happy with any of the ways I've tried to manage settings. It's especially difficult while taking advantage of a project like Pinax where you're managing settings for Pinax applications that might change from version to version, settings for 3rd-party applications that might change and settings for any project- specific applications, all of which might need overridden in complex ways depending on the environment. I definitely think it's something with room for improvement.
I also love the debian-style configurations for my system in general. I guess the question I have about borrowing that style for configuration files in python is whether or not there's a burden when debugging and managing settings. Just brainstorming, but all of the configuration setups I've seen with multiple files and overrides have been totally declarative. Is giving someone the flexibility of python across multiple files but in one namespace too much? I suppose we're already kind of in that situation with application-level defaults and such, though. >From a deployment standpoint, I definitely see a big advantage to this multiple-file style of configuration. Right now I have some hacky fabric tasks that use a mixture of string templating and sed to cajole my settings_local to the specific combination of settings for continuous integration, test, staging, beta, live, local etc. deployments. It kind of sucks. -Wes On Feb 23, 6:22 pm, Carl Meyer <[email protected]> wrote: > 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. > > cheers, > > Carl > > [1]http://code.djangoproject.com/wiki/SplitSettings#Usingalistofconffile... -- 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.
