Jim wrote: On Sep 5, 9:25 am, brad <[EMAIL PROTECTED]> wrote:
I've also run into the problem of keeping my settings.py under version control, so I just created multiple settings files for the various servers on which my apps would run, so I've got: settings.py settings_server1.py settings_server2.py settings_dev.py I know this violates DRY to some degree, but it's fairly easy to just copy the appropriate settings file over to settings.py whenever I deploy the app. I have an installation-from-repo routine that, in part, looks up the hostname and generates the appropriate settings.py (and some other stuff) and puts it where it should go. Obviously the installation routine costs me a certain effort of coding, debugging, etc., so it may not be worth it for some projects, but at least it solves that problem. For a given project I have one settings.py file that is used across several dev/prod servers. My settings file checks the hostname and adjusts the config accordingly. This approach seems to be working okay for me so far but time will tell. For example: from socket import gethostname ... DEV_HOSTS = ["server1", "server2", "server3"] DEV_MODE = gethostname() in DEV_HOSTS ... TEMPLATE_STRING_IF_INVALID = "--INVALID-TEMPLATE-VARIABLE--" if DEV_MODE else "" The ability to do this is IMHO a nice side-effect of the settings file being executable Python code (as opposed to, say, a static XML config file). However I try to avoid having too much dynamic stuff in the settings file. Bob. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
