Ma surcouche définit pas mal de settings par défaut (a priori viables, genre USE_TZ = True), ensuite mon projet donne d’autres settings (ou écrase certains précédents) et je cherche enfin dans des fichiers de conf (./local_settings.{py|ini} et $VIRTUALENV/etc/monprojet/settings.{py|ini}). On a ensuite une fusion de ces 6 différentes sources de settings.

Au final :

la grande majorité des settings sont définis une seule fois dans mon socle applicatif,
quelques settings sont overridés dans chaque projet (parfois seulement 3 ou 4),
en dév’, j’ai uniquement un fichier supplémentaire (local_settings.py) à la racine du projet contenant en général DEBUG=True,
quand je déploie (avec pip install monprojet, rien de plus), je dois écrire un fichier de conf’ normal (au format .ini), sachant que j’ai une commande Django qui me donne son emplacement et son contenu avec les valeurs actuelles,
je n’ai plus à gérer plusieurs fichiers de settings avec 99% de choses en commun et qu’il faut mettre à jour à chaque modif,
les mises à jour se font via pip install monprojet --upgrade (avec migrate et collecstatic) et n’affectent pas le fichier de conf local.

Après la fusion, il y a une analyse des settings, pour faire des références entre settings, créer automatiquement des dossiers, … sachant que toutes les strings sont par défaut interprétées comme des string.format.

Par exemple, les settings fournis par mon socle définissent :

DATABASES = {'default': {
    'ENGINE': CallableSetting(database_engine, 'DATABASE_ENGINE'), 'NAME': '{DATABASE_NAME}', 'USER': '{DATABASE_USER}',
    'PASSWORD': '{DATABASE_PASSWORD}', 'HOST': '{DATABASE_HOST}', 'PORT': '{DATABASE_PORT}'},
}

Quand je déploie, j’ai uniquement à écraser DATABASE_NAME, DATABASE_USER, DATABASE_PASSWORD, DATABASE_HOST et DATABASE_PORT dans le fichier de settings local (les valeurs par défaut utilisent du sqlite, histoire d’avoir un truc utilisable par défaut).

J’ai également une liste de correspondances entre les settings Python à personnaliser (genre DATABASE_NAME) et le format .ini (database.name, pour chercher l’option name dans la section [database]).

Grâce à la possibilité d’appeler du code après la fusion, je peux faire des choses assez complexes : si je définis les coordonnées Redis dans la section [cache] ou celles du LDAP dans la section [auth], j’ajoute les packages à INSTALLED_APPS et je vérifie que les packages sont installés.

Et pour revenir au sujet, SECRET_KEY est défini par un callable qui tente de lire un fichier, et s’il n’existe pas, le crée en générant son contenu => une nouvelle clef est générée lors de chaque déploiement et reste persistante sur la machine, de façon transparente.

– les mettre dans le bashrc de ton utilisateur

– les mettre dans un fichier X ou Y et sourcer celui-ci à la volée et ensuite lancer ton appli

– etc…

c’est le même mécanisme que quand tu utilises des virtualenv par exemple…

si une machine redémarre, les variables d’environnements sont t’elles sauvegardées?

Peut être que ce sont des settings additionnels qui lient les MdP à la clé.

parfois les débutants, veulent absolument trouver des trucs simple avant les vrais dev lol

Ca évite aussi l’erreur classique de la clé commitée dans git par le stagiaire si secret_key est déjà dans le .gitignore ou la mise en prod où on oublie la clé.

Enfin on ne doit surtout pas changer la clé à chanque lancement, car les mots de passes en bdd de django.contrib.auth sont hashés avec la clé, et un changement invaliderait tous les mots de passe.

Désolé suis un débutant, mais une question me taraude.

quelle différence cela fait t’il entre un clef visible ( SECRET_KEY =’bvqsdhkjh…”), et une clef à priori cachée (SECRET_KEY=get_secret_key(‘secret_key’))

ne peut t’on pas de toute façon affiché SCRET_KEY?

et pourquoi du coup ne pas faire en python 3.6 :

from secrets import token_urlsafe

SECRET_KEY = token_urlsafe(37)

la clef serait différente à chaque démmarage

merci d’avance

@Oscar LASM: c’est bien si tu utilise les env vars. Mais je m’appercois de plus en plus que 90% des devs ne savent même pas ce que c’est. Déjà sous windows…

Moi j’utilise django-environ pour gérer mes settings