django: settings.py aplikacji w trybie devel i production

Piszesz aplikację w django, wysyłasz na serwer i musisz zmienić settings.py aby dostosowane były do wersji produkcyjnej. I tak za każdym razem, kiedy coś zmieniasz. Dodatkowo kod utrzymywany jest w systemie kontroli wersji i nie chcesz aby hasła były dostępne publicznie. Sprawa wydaje się skomplikowana ale tylko wydaje a rozwiązań jest sporo. Ja zaprezentuję to które ja wybrałem, a może nawet wymyśliłem, bo jest ono sumą paru rozwiązań. Przyznaję, że nie jest doskonałe ale przynajmniej nie muszę ręcznie zmieniać ścieżek ani danych dostępowych do bazy danych.

Załóżmy hipotetycznie, że posiadasz dwie wersje: lokalną (deweloperską) i zdalną (produkcyjną). Lokalna używa django do serwowania plików a zdalna apacha czy nginxa lub czegoś innego. Mało ważne czego, istotną sprawą jest to, że pliki settings.py się różnią (urls.py również ale do tego wrócę pod koniec artykułu). Jest parę podejść które można sobie podejrzeć na wiki. W moim przypadku zastosowałem import wielu plików settings, w zależności od wersji aplikacji. Jeśli w drodze ewolucji programistycznej zmienię sposób to nie omieszkam tego opisać (Omieszkam – trudne słowo, podobno nastolatki zbyt namiętnie używające komunikacji internetowej korzystają średnio z 800 słów. Całe szczęście nie jestem jednym ani drugim).
Posiadając dwie wersje dobrze stworzyć dwa dodatkowe pliki settings.py, powiedzmy, że będzie to settings_devel.py oraz settings_prod.py. Pamiętaj, że chcesz również ukryć hasła przed wścibskimi oczami ludźmi przeglądających Twój kod na Launchpadzie czy innym Gicie. Z pliku settings.py usuwasz dane które chcesz ukryć oraz ustawienia specyficzne dla rodzaju instalacji, np: hasła do bazy danych i flagę DEBUG. Kiedy masz już gotowe oba pliki, koniecznie usuwasz je ze swojego systemu kontroli wersji aby przypadkiem nie udostępnić ich publicznie. Należy teraz podrasować swój plik settings.py, względna ścieżka TEMPLATE_DIRS od katalogu aplikacji jest zazwyczaj taka sama więc do generowania jej możesz użyć poniższego kodu:

import os
BASE_DIR = os.path.dirname(os.path.abspath(__file__))
....
TEMPLATE_DIRS = (
    BASE_DIR + '/templates/'
)

Dzięki temu niezależnie od wersji aplikacji ścieżka do templates będzie poprawna. Teraz czas na ładowanie haseł oraz innych ścieżek. To wygląda mniej przyjemnie z punktu widzenia urody kodu. Chociaż ostatni przykład do najpiękniejszych również nie należy.
Ja użyłem następującego rozwiązania. Do pliku settings.py dodałem zmienną, której wartość określa jaki plik ma zostać zaimportowany.

MODE = 'DEVEL'

A następnie kod, który załaduje odpowiedni plik.

if MODE == 'PROD':
    try:
        from settings_prod import *
    except:
        pass
else:
    try:
        from settings_devel import *
    except:
        pass

Użycie komendy else spowoduje załadowanie ustawień deweloperskich w wypadku braku MODE lub literówki, przydatne gdy masz dostęp z jednej maszyny do obu baz danych i jesteś zapominalski. Teraz pliki settings ładujesz do aplikacji i zmieniasz MODE w zależności od trybu pracy.
Wracając do pliku urls.py, a dokładnie chodzi mi o wpis

(r'^templates/static/(?P<path>.*)$',
'django.views.static.serve',
{'document_root': os.path.join(os.path.dirname(__file__), '/home/michal/Projects/django/gdzie_byl_kaziu/templates/static')}),

W wersji produkcyjnej za serwowanie plików statycznych jest odpowiedzialny serwer www ale to też można zmodyfikować jeśli będzie taka potrzeba. Urlpatterns można rozszerzać, na przykład

if settings.MODE == 'LOCAL':
    urlpatterns += patterns('',
                            (r'^templates/static/(?P<path>.*)$',
                             'django.views.static.serve',
                             {'document_root': os.path.join(os.path.dirname(__file__), '/home/user/projects/templates/static')}))

Zaprezentowane rozwiązanie nie jest idealne ponieważ nadal trzeba pilnować jaki tryb jest włączony ale dużo bardziej wygodne niż komentowanie całych linijek w settings.py. Z miłą chęcią przeczytam o innych sposobach rozdzielania ustawień.