TechLife devBlog

Czerwiec 2009

Django – personalizacja settings.py

Kodowanie, Django, Techblog 28 czerwca 2009 11:17

Jak każdy djangowic dobrze wie plik settings.py przechowuje wszelkie ustawienia aplikacji począwszy od nazwy strony a na listach middleware'u czy liście zainstalowanych aplikacji skończywszy. Ponieważ zawiera on wszelkie ustawienia, musi być inny dla developera a inny dla serwera produkcyjnego (np. z powodu tego, że developer ma DEBUG=True).

Pierwszą możliwością rozwiązania tego problemu jest ignorowanie pliku settings.py przez repozytorium kodu, tak aby różne zawartości tego pliku nie powodowały konfliktów. Wadą takiego rozwiązania jest potrzeba ręcznego edytowania tego pliku na serwerze kiedy np. dodajemy nową aplikację do INSTALLED_APPS. Moje repozytorium aktualizuje stronę na serwerze po każdym commicie, więc ręczna edycja settings.py jest męcząca.

Drugą możliwością jest stworzenie osobnych ustawień dla serwera i osobnych dla developera. Django umożliwia uruchomienie serwera z podaniem pliku ustawień jako parametr:

python manage.py runserver --settings=settings-developer.py

Wszystko wydaje się być ok. Jeżeli coś zmieniamy to dokonujemy zmiany w settings.py, settings-developer.py i po commitcie wszystko gra. Czasami jednak przy testowaniu różnych rzeczy w pliku developera można zapomnieć o settings.py i po commicie znowu strona jest rozwalona. Poza tym nie każdy developer korzysta z tych samych ustawień. Jeden używa Django Debug Toolbar inny ColorSQLMiddleware więc trzeba by zrobić tyle settings-xxx ilu developerów. A później przy zmianie czegoś globalnego edytować wszystkie...

Ostatecznym rozwiązaniem okazało się przeciążenie pliku settings.py przez ponowną deklarację zmiennych lub rozszerzenie już istniejących wartości. Jak to zrobić?

  1. Tworzymy plik, który będzie przetrzymywał nasze lokalne ustawienia, np. settings-local.py
  2. Na końcu pliku settings.py dodajemy kod:
BASE_DIR = os.path.dirname(os.path.abspath(__file__))
execfile('%s/settings-local.py' % BASE_DIR)

Teraz w pliku settings-local.py możemy ponownie zadeklarować zmienne które mają zostać przeciążone lub rozszerzyć zadeklarowane już w settings.py listy. Np. kiedy jeden z developerów chce użyć Django Debug Toolbar dodaje do settings-local.py taki kod:

MIDDLEWARE_CLASSES += (
    'debug_toolbar.middleware.DebugToolbarMiddleware',
)

INSTALLED_APPS += (
    'debug_toolbar',
)

DEBUG_TOOLBAR_PANELS = (
    'debug_toolbar.panels.sql.SQLDebugPanel',
    'debug_toolbar.panels.headers.HeaderDebugPanel',
    'debug_toolbar.panels.cache.CacheDebugPanel',
    'debug_toolbar.panels.profiler.ProfilerDebugPanel',
    'debug_toolbar.panels.request_vars.RequestVarsDebugPanel',
    'debug_toolbar.panels.settings_vars.SettingsVarsDebugPanel',
    'debug_toolbar.panels.templates.TemplatesDebugPanel',
    # If you are using the profiler panel you don't need the timer
    # 'debug_toolbar.panels.timer.TimerDebugPanel',
)

Plik settings-local.py wywalamy z repozytorium i w ten sposób otrzymujemy elastyczny mechanizm współdzielenia wartości globalnych przy jednoczesnej personalizacji ustawień lokalnych.

Narzędzia do pracy grupowej poszukiwane

Internet, Kodowanie 4 czerwca 2009 15:40

Obecnie pracuję jako programista aplikacji internetowych w małym zespole. Realizujemy kilka projektów w miesiącu i dość trudno jest zapanować nad wszystkimi zadaniami, które trzeba wykonać. W przypadku większych projektów korzystamy z Trac'a, jednak do mniejszych nie nadaje się on za dobrze ponieważ trzeba dla każdego projektu tworzyć nową instancję i nie ma jak zrobić zbiorczego zestawienia. Rozglądałem się więc za jakimś kompleksowym rozwiązaniem, które dawałoby możliwość ogarnięcia kilku projektów wraz ze śledzeniem repozytoriów Subversion.

Powstało już wiele serwisów oferujących podobną funkcjonalność. Wśród najbardziej znanych wymienić można:

Główną wadą pierwszych trzech rozwiązań jest to, że nie można ich hostować na własnym serwerze a jedynie wykupuje się konto na serwerze producenta. Collabtive jest co prawda aplikacją na licencji GNU GPL i można postawić to u siebie, ale z kolei zupełnie nie obsługuje repozytoriów kodu.

I tutaj pytanie do Was. Czego Wy używacie w pracy? Być może jest jakiś fajny projekt który przeoczyłem.

PS. Swoją drogą to dziwne, że nikt jeszcze czegoś podobnego w Django nie zrobił.