it-swarm.com.de

Lokale Django-Einstellungen

Ich versuche local_setting in Django 1.2 zu verwenden, aber es funktioniert nicht für mich. Im Moment füge ich meinem Projekt nur local_settings.py hinzu.

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.
    }
}

Das Problem ist, dass local_settings.py settings.py ..__ nicht überschreibt. Was ist falsch?

64
Michel Andrade

Sie können local_settings.py nicht einfach hinzufügen, Sie müssen sie explizit importieren.

Fügen Sie am very end Ihrer Einstellungen.py Folgendes hinzu:

try:
    from local_settings import *
except ImportError:
    pass

Der try/except-Block ist vorhanden, so dass Python den Fall einfach ignoriert, wenn Sie noch keine local_settings-Datei definiert haben.

115
Daniel Roseman

Dies ist die beste Methode, die ich denke:

  • local_settings importiert von settings
  • local_settings überschreibt Einstellungen, die für die lokale Umgebung spezifisch sind, insbesondere DATABASES, SECRET_KEY, ALLOWED_HOSTS und DEBUG
  • Übergeben Sie an Django-Verwaltungsbefehle das Flag --settings=local_settings

Sie könnten local_settings folgendermaßen implementieren:

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.
    }
}

Einige weitere wichtige Punkte:

  • settings.py befindet sich in der Versionskontrolle und ist so geschrieben, dass es von Mitwirkenden verwendet werden kann
  • local_settings.py (oder häufiger prod_settings.py) befindet sich NICHT in der Versionskontrolle und wird in der Produktion durch Angabe von --settings=prod_settings oder ähnlichem verwendet.

Wenn Sie die Datei mit den Bestandseinstellungen so wenig wie möglich berühren, können Sie auch die Aktualisierung Ihrer Django-Version einfacher durchführen. Wenn Sie ein Upgrade von Django auf die nächste Version durchführen, sollten Sie sich den Unterschied im Lager settings.py und in Ihrem ansehen und je nach Änderung Maßnahmen ergreifen. Änderungen an den Standardwerten können wichtig sein. Je weniger Sie die ursprüngliche settings.py-Datei berührt haben, desto leichter lassen sich Upstream-Änderungen erkennen.

65
janos

Da das Thema immer wieder neu erscheint, lassen Sie mich zusammenfassen, warum Sie diesen Ansatz in Betracht ziehen sollten:

  • eine dumme Einstellungsdatei ist sehr schnell und einfach zu ändern; insbesondere in einer Produktionsumgebung. Kein Python erforderlich: Jeder Idiot kann einspringen und das Datenbankkennwort in einer Datei ändern, in der nur Namen und Werte aufgeführt sind. vor allem im Vergleich zu einer komplexen Python-Einstellungsdatei voller mysteriöser gefährlicher BIGCAPS-Namen.

  • die Anwendung settings sollte vollständig von der Anwendung code getrennt sein. Sie können eine config.ini außerhalb des Repository-Stammverzeichnisses ablegen und sich nie wieder Gedanken darüber machen, dass ein Repo-Pull Ihre Einstellungen oder Ihre persönlichen Einstellungen verschmutzt, die das Repo verschmutzen, oder dieser clevere Code in Ihren Einstellungen.py, die ihn nicht zum Vorteil aller anderen machen .

Dies gilt nicht für kleine Projekte, aber bei größeren Projekten bin ich zu dem Schluss gekommen, dass die local_settings-Strategie sie nicht schneidet. mit der Zeit schleicht sich die Anwendungsprogrammierung dahin, dass sie schwer zu handhaben ist in erster Linie, wenn Einstellungen abzuleiten und/oder abhangig sind. Es kann gute Gründe dafür geben, dass Einstellungen entsprechend den lokalen Einstellungen reagieren, wodurch der Import einer local_settings-Datei in die Mitte von settings.py schleichen muss. Ich finde, dass die Dinge unordentlich werden, wenn das passiert.

Meine derzeitige Lösung ist die Verwendung einer config-Datei, die ich "local.ini" übersetze. Sie enthält nur die Werte, die sich tatsächlich zwischen den bereitgestellten Instanzen ändern. Es gibt keinen Code: Sie sind nur Werte und Booleans:

[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

Damit kann ich den settings.py wie jeden anderen Anwendungscode behandeln: Passen Sie ihn an, checken Sie ihn ein und stellen Sie ihn bereit, ohne sich Gedanken darüber machen zu müssen, ob der Code in einem local_settings-Python-Code lauert. Mein settings.py ist frei von Race-Bedingungen, die auftreten, wenn spätere Einstellungen von lokalen Einstellungen abhängen, und ich kann Funktionen ein- und ausschalten, indem ich einfach zu verfolgenden linearen Code schreibe. Nicht mehr schnell die Datei local_settings anpassen, wenn ich vergessen habe, einen neuen Wert hinzuzufügen, und keine daves_local_settings.py- und bobs_local_settings.py-Dateien mehr, die sich in das Repository schleichen.

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'

Wenn Sie auf ein BOFH stoßen, wie ich es bei einer Gelegenheit hatte, war er besonders aufgeregt über die Möglichkeit, den local.ini als /etc in das /etc/ourapp.ini-Verzeichnis einzufügen und so das Anwendungsverzeichnis selbst als reinen Repository-Export zu erhalten. Sicher, Sie könnten das mit local_settings.py machen, aber das Letzte, was er wollte, war, sich mit Python-Code zu beschäftigen. Eine einfache Konfigurationsdatei, mit der er umgehen konnte.

10
John Mee

Ich habe eine Kopie von __local_settings.py behalten:

  • local_settings.py wird in der Versionskontrolle ignoriert, aber nicht __local_settings.py
  • aktualisieren Sie README.md, um das Team über das Setup zu informieren: cp {__,}local_settings.py (die eine Kopie für ihre local_settings erstellen)

In der Vergangenheit

Ich habe diese Einstellungen importiert.

# settings.py
DATABASE = {...}

try:
    from .local_settings import *
except ImportError:
    pass

jetzt

Ich importiere einfach die Einstellungen selbst aus dem local_settings.py

Und mit dem folgenden Befehl: python manage.py runserver --settings=<proj>.local_settings

# local_settings.py & __local_settings.py
from .settings import *

DATABASE = {...}

Und da ich normalerweise nicht direkt mit manage.py interagiere, da einige Parameter für mich explizit notwendig sind (z. B. address:port). Deshalb stelle ich all diese Befehle in meine Makefile.

Zum Beispiel mein Makefile:

run:
    python manage.py runserver 0.0.0.0:8000 --settings=<proj>.local_settings

sh:
    python manage.py Shell_plus --settings=<proj>.local_settings

dep:
    npm install
    pip install -r requirements.txt

Somit:

make dep
make sh 
make run

Fazit

Vorausgesetzt, Sie sind nicht und verwenden Makefile als Workflow, können Sie die frühere Methode verwenden. Wenn Sie jedoch Makefile verwenden, ist es meiner Meinung nach besser, in Ihrem Makefile expliziter zu sein. 

4
Yeo

Bevor Sie den Server ausführen, tun Sie dies

export Django_SETTINGS_MODULE=your_app_name.local_settings wobei Ihr_App_name durch den Namen Ihrer App ersetzt werden soll . Und vergiss nicht zu tun 

from settings import *

in Ihrer Datei local_settings.py

3
Siddhesh Suthar

Fügen Sie dies am Ende der Datei "settings.py" hinzu

try:
    from .local_settings import *
except ImportError:
    pass

Erstellen Sie beispielsweise die Datei local_settings.py mit Ihren neuen Einstellungen

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.
    }
}
0
Holovin

Ein weiterer Ansatz ist die Verwendung von python-dotenv und Umgebungsvariablen, um Einstellungen für verschiedene Umgebungen anzupassen. 

Erstellen Sie die .env-Datei zusammen mit Ihrem settings.py:

# .env
SECRET_KEY=your-secret-key
DATABASE_PASSWORD=your-database-password

Fügen Sie Ihrem settings.py den folgenden Code hinzu:

# settings.py
from dotenv import load_dotenv
load_dotenv()

# OR, explicitly providing path to '.env'
from pathlib import Path  # python 3.4+
env_path = Path('.') / '.env'
load_dotenv(dotenv_path=env_path)

Zu diesem Zeitpunkt sind geparste Schlüssel/Werte aus der .env-Datei als Umgebungsvariablen vorhanden und können bequem über os.getenv() abgerufen werden:

# settings.py
import os
SECRET_KEY = os.getenv('SECRET_KEY')
DATABASE_PASSWORD = os.getenv('DATABASE_PASSWORD')   
0
Eugene Yarmash

Ich habe die ähnliche Lösung gefunden. Dies ist meine Konfiguration für diesen Fall:

settings.py:

DEBUG = False

try:
    from local_settings import *

except ImportError:
    pass

if DEBUG is False:
    ALLOWED_HOSTS = ['sth.com']
    DATABASES = {
        ....
    }

local_settings.py:

from settings import *
ALLOWED_HOSTS = ['*']
DEBUG = True
DATABASES = {
    ...
}
0
Darex1991