Django Local Settings

Question

Je suis en train d'utiliser local_setting dans Django 1.2, mais il ne fonctionne pas pour moi. Pour le moment je suis juste en ajoutant local_settings.py de mon projet.

settings.py

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'banco1',                      # Or path to database file if using sqlite3.
        'USER': 'root',                      # Not used with sqlite3.
        'PASSWORD': '123',                  # Not used with sqlite3.
        'HOST': 'localhost',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}

local_settings.py

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'banco2',                      # Or path to database file if using sqlite3.
        'USER': 'root',                      # Not used with sqlite3.
        'PASSWORD': '123',                  # Not used with sqlite3.
        'HOST': 'localhost',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}

Le problème est qu' local_settings.py ne pas surcharger settings.py. Quel est le problème?

Answer 1

Vous ne pouvez pas simplement ajouter local_settings.py, vous devez explicitement à l'importation.

À la fin de votre settings.py, ajoutez ceci:

try:
    from local_settings import *
except ImportError:
    pass

Le try/except bloc n'est là que pour Python ignore juste au cas où vous n'avez pas défini un local_settings fichier.

Answer 2

C'est la meilleure pratique, je pense que:

• local_settings des importations de settings
• local_settings remplace les paramètres spécifiques à l'environnement local, en particulier DATABASES, SECRET_KEY, ALLOWED_HOSTS et DEBUG variables
• passer à django commandes de gestion de l'indicateur --settings=local_settings

Vous pouvez implémenter local_settings comme ceci:

from settings import *

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'banco2',                      # Or path to database file if using sqlite3.
        'USER': 'root',                      # Not used with sqlite3.
        'PASSWORD': '123',                  # Not used with sqlite3.
        'HOST': 'localhost',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}

En général, vous écrivez settings.py d'une manière qu'il est approprié pour des fins de développement. Dans un environnement de production vous utilisez --settings=local_settings pour remplacer certains paramètres comme nécessaire.

Le toucher fichier de paramètres aussi peu que possible rend également plus facile de mettre à niveau votre version de django.

Answer 3

Cela ne s'applique pas pour des petits projets, mais sur les grands projets j'en ai conclu que le local_settings stratégie ne coupe pas; avec le temps, assez de programmation d'application s'insinue qu'il devient difficile à gérer, surtout que les paramètres sont dérivés et/ou de codépendance. Il peut y avoir de bonnes justifications pour les paramètres de réagir en fonction des paramètres locaux où les forces de l'importation d'un local_settings le fichier à ramper vers le haut, vers le milieu de l' settings.py. - Je trouver les choses commencent à devenir bordélique que ça se passe.

Ma solution actuelle est d'utiliser un config le fichier, je dub "local.ini". Il ne contient que les valeurs qui ne change effectivement entre les instances déployées. Il n'y a pas de code: ce sont juste des valeurs et des booléens:

[global]
domain = 127.0.0.1:8000
database_host = 127.0.0.1
database_name = test_database
debug = Yes
google_analytics_id = UA-DEV-1
payments = testing
use_cdn = No

Avec cela en place, je peux traiter l' settings.py comme n'importe quel autre morceau de code de l'application: le tordre, de le vérifier, et de le déployer sans avoir à vous soucier de l'essai contre n'importe quel code qui pourrait se cacher dans un local_settings code python. Mon settings.py est libre de conditions de course qui nous viennent quand plus tard les paramètres dépendent de paramètres locaux, et je peux le commutateur de fonctions sur et en dehors de l'écriture facile à suivre linéaire de code. Pas plus hâte de modifier les local_settings fichier si j'ai oublié d'ajouter une nouvelle valeur, et plus daves_local_settings.py et bobs_local_settings.py fichiers rampante dans le référentiel.

from ConfigParser import RawConfigParser
parser = RawConfigParser()

APPLICATION_ROOT = path.abspath(path.dirname(__file__))
parser.readfp(open(path.join(APPLICATION_ROOT, 'local.ini')))

# simple variables
DATABASE_HOST = parser.get('global', 'database_host')
DATABASE_NAME = parser.get('global', 'database_name')

# interdependencies
from version import get_cdn_version
CDN = 'd99phdomw5k72k.cloudfront.net'
if parser.getboolean('global', 'use_cdn'):
    STATIC_URL = '/{}/static/{}/'.format(CDN, get_cdn_version())
else:
    STATIC_URL = '/static/'


# switches
payments = parser.get('global', 'payments')
if payments == 'testing':
    PAYMENT_GATEWAY_ENDPOINT = 'https://api.sandbox.gateway.com'
else:
    PAYMENT_GATEWAY_ENDPOINT = 'https://api.live.gateway.com'

Si vous rencontrez un BOFH, comme j'ai eu à une occasion, il s'est particulièrement excité à propos de la capacité à adhérer à l' local.ini dans la /etc répertoire /etc/ourapp.ini et ainsi de garder le répertoire de l'application elle-même un pur référentiel à l'exportation. Assurez-vous que vous pouvez le faire avec une local_settings.py mais la dernière chose qu'il voulait faire, c'était le désordre avec du code python. Un simple fichier de configuration, il pourrait manipuler.

Puisque le sujet a refait surface peut-être cette approche pourrait aider quelqu'un.