Django Settings

Nachdem Martin grade seine settings.py mit einigen netten Kniffen gebloggt hat, möchte ich kurz die Gelegenheit nutzen und auch ein paar Dinge zum Thema Django settings.py bloggen, die ich schon länger benutze.

Lokale Settings

Die Mehrheit der Django Entwickler benutzt mittlerweile einen Mechanismus, wie ihn Martin beschreibt und trennt die settings.py in eine settings.py und lokale Settings-Datei, die am Ende der settings.py importiert wird auf. Der Vorteil ist hierbei, dass keine sensiblen Daten, wie etwa der SECRET_KEY oder das DATABASE_PASSWORD in der Versionsverwaltung landen. Dies ist besonders bei OpenSource Projekten, die auf Google-Code oder GitHub liegen sehr wichtig. Was mich nur wundert ist, dass die Mehrheit der Leute (zumindestens, die die drüber bloggen) die Dateien settings.py und local_settings.py nennt. Ich habe mir angewöhnt die Dateien settings.py und settings_local.py zu nennen, damit liegen diese nämlich beim betrachten des Ordners (z.B. auf der Shell) direkt untereinander und es minimiert Fehler, bei denen ein Entwickler z.B. die lokale Settings-Datei übersieht, die ein anderer angelegt hat.

Bei mir sieht das Ende der settings.py also immer so aus:

try:
    from settings_local import *
except ImportError:
    pass

Relative Pfade

Um die settings.py möglichst generisch zu halten gehört es mittlerweile zu den Best-Practices Pfade, wenn möglich relativ zur settings.py anzugeben und nicht absolut (spezifisch für den Server). Wenn absolute Pfade notwendig sind gehören diese in die lokale Settings-Datei (siehe oben). Das einfachste Konstrukt zur Angabe lokaler Pfade sieht so aus (am Beispiel des Template Ordners, ausgehend davon, dieser im Projekt-Ordner liegt und 'templates' heißt):

import os
...
TEMPLATE_DIRS = (
    os.path.join(os.path.dirname(__file__), 'templates'),
)

Wenn man solch relative Pfade öfter braucht ist das jedoch relativ viel Tipparbeit und sieht nicht so schön aus, da für wenig funktionalität relativ viel Code benötigt wird. Typische Kanidaten, wo man noch relative Pfade benutzen könnte sind z.B. DATABASE_NAME beim Einsatz von SQlite oder MEDIA_ROOT, wenn es im Projekt-Ordner liegt, weil man z.B. Sytlesheets mit versioniert. Eine Methode, die ich mittlerweile einsetze funktioniert wie folgt (wieder am Beispiel der TEMPLATE_DIRS):

import os
rel = lambda p: os.path.join(os.path.dirname(__file__), p)
...
TEMPLATE_DIRS = (
    rel('templates'),
)

Sicherlich lohnt das definieren der Funktion nicht, wenn man sie nur einmal benötigt, aber bei 3 oder mehr relativen Pfaden macht es die settings.py übersichtlicher finde ich.

Veröffentlicht von Arne Brodowski am 17. Dez. 2008, 08:58 in , , , .

Verwandte Einträge

Kommentare