Whatever configuration system using variables of a language is a disaster and it's going not maintainable as has been showed in Django.
My solution was to use YAML, and then to use a class to convert it to Python. Features: * The python configuration is only re-built if yaml config. has been changed. * It can add some configuration depending of some variable, as debug. See in lines where is '?'. * It adds the absolute paths where it's necessary. - YAML config. initial => http://pastebin.com/CVqGD1eL - Python generated => http://pastebin.com/AB4FaBgy On 23 feb, 23:22, 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.
