On Feb 27, 2010, at 5:30 PM, Brian Rosner wrote: > > On Feb 25, 2010, at 12:08 AM, Carl Meyer wrote: > >> 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. > > This little bit has left me a bit uneasy. I spent some time thinking about it > on my back from PyCon and think I have a slightly better solution. > > We have a lot of duplication of environment bootstrapping in many of the > project-level files. manage.py and deployment files. It occurred to me this > can be cleaned up. I started a new branch for this clean-up [1]. What we can > do based on this branch is set DJANGO_SETTINGS_MODULE to something like > pinax.conf.settings where we can run the code to setup project-level > settings. We likely will need to set an environment variable to store the > location of conf directory. I find this a decent improvement in terms of > setup. Any obvious issues or thoughts on this?
An obvious issue I didn't consider at first is handling of multiple settings files. If we hijack DJANGO_SETTINGS_MODULE this breaks all cases where users might be relying on it or --settings (to many management commands) to point to another settings file. I am going to need to go back to the drawing board on that bit. The rest of my work on new_env branch seems sane enough and cleans up the code some to make it more maintainable. Brian Rosner http://oebfare.com http://twitter.com/brosner -- 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.
