Hey Wes; my experience has been that this system isn't any more complex to manage than, say, Apache Debian config files. With the full power of Python, clearly it would be possible for a user to do all sorts of insane things in their config files; but that's true of settings.py to begin with. And yes, this system is a big improvement for deployment scenarios.
So I've got a demo implementation of this in Pinax in my settings- proposal branch: http://github.com/carljm/pinax/commit/1ca3865a40fd04388d542dd468486183b7367d64 So far it's only implemented in basic_project, and I more or less just moved the current settings.py to conf/05_pinax.py; I didn't yet do any refactoring into multiple files to take advantage of the new system. I think that piece would be better done by someone more familiar with Pinax. The settings.py file in the project is quite small; most of the real functionality is imported from pinax.utils.conf (where I arbitrarily placed it; let me know if I should move it elsewhere). There's a bit of a locals() dance that has to be done in order to move the actual exec-ing into imported code, but get the resulting settings back into the settings.py local namespace. Any thoughts or objections? If the core devs are +1 on moving forward with this, I'll implement it in the other projects. Carl -- 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.
