settings modul: egy jobb megközelítés

Django alapú fejlesztések eltérő környezeteinek (fejlesztői, teszt, éles stb.) beállítására korábban bemutatott módszert közelítem meg más szemszögből. RePa jegyezte fel, hogy javaslatomnál talán még rugalmasabb, ha mellőzzük a local_settings.py használatát, és közvetlenül a megfelelő settings modult töltjük be a DJANGO_SETTINGS_MODULE segítségével.

Ennek a javaslatnak számos előnye van.

  • Annak érdekében, hogy verziókezelten tároljuk valamennyi környezet beállításait, eddig a verziókezelőbe nem bejegyzett local_settings.py-ban hivatkoztunk a megfelelő modulra. Új környezet kialakításakor potenciális hibaforrás, ha ennek létrehozására elfeledkezünk. Erre most nincs szükség.
  • WSGI konfiguráció esetén a .wsgi skriptben definiáljuk a DJANGO_SETTINGS_MODULE-t. Praktikusan minden környezethez saját WSGI skriptet társítunk, így minden további nélkül jelölhetjük a környezethez tartozó settings modult is. Ez új tehert nem ró ránk.
  • Míg korábban a settings modul végén hívtuk be a környezetfüggő beállításokat, most a környezet settings moduljának elején töltjük be a közös metszetet. Ez működés szempontjából lényegtelen.

Az új megközelítés szerint tehát a gyári settings.py-t modullá konvertáljuk settings/__init__.py néven, majd a környezeti konfigurációkat a korábbiakhoz hasonlóan devel.py, prod.py stb. néven elmentjük. A változás tehát, hogy a devel.py elején töltjük be a settings modult.

# devel.py
from csodanyul.settings import *
# apache.wsgi
os.environ['DJANGO_SETTINGS_MODULE'] = 'csodanyul.settings.devel'

A módszer egyedül a management parancsok hívásakor jelenthet gondot. Tudniillik a manage.py megrögzötten a settings nevű modult fogja betölteni fittyet hányva a DJANGO_SETTINGS_MODULE értékére.

Részlet a manage.py tartalmából:

#!/usr/bin/env python
from django.core.management import execute_manager
try:
    import settings # Assumed to be in the same directory.

Nem mellesleg ez a viselkedés (nevezzük bátran bugnak) dokumentált a Django Bookban.

Renaming settings.py

Feel free to rename your settings.py to settings_dev.py or settings/dev.py or foobar.py — Django doesn’t care, as long as you tell it what settings file you’re using.

But if you do rename the settings.py file that is generated by django-admin.py startproject, you’ll find that manage.py will give you an error message saying that it can’t find the settings. That’s because it tries to import a module called settings. You can fix this either by editing manage.py to change settings to the name of your module, or by using django-admin.py instead of manage.py. In the latter case, you’ll need to set the DJANGO_SETTINGS_MODULE environment variable to the Python path to your settings file (e.g., 'mysite.settings').

A megoldás tehát az, hogy a DJANGO_SETTINGS_MODULE beállítása mellett a jövőben a Django disztribúcióval érkező django-admin.py skriptet használjuk. A manage.py lényegében a django-admin.py köré húzott burkoló, ami annyit tesz, hogy a projekt könyvtárát pathra teszi, továbbá beállítja azt a DJANGO_SETTINGS_MODULE környezeti változót, amelynek amúgy értékét ő maga nem veszi figyelembe.

Mindezen kitétel ellenére egy letisztultabb megoldást nyújt RePa megközelítése, hovatovább a szükséges PATH, PYTHONPATH és DJANGO_SETTINGS_MODULE változók például virtualenv használatakor egyszerűen megadhatók a környezet bekapcsolásakor.

08okt.

Szólj hozzá