Джанго Локальные настройки

Question

Я пытаюсь использовать local_setting в Django 1.2 , но у меня это не работает. На данный момент я просто добавляю local_settings.py в мой проект.

settings.py

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'banco1',                      # Or path to database file if using sqlite3.
        'USER': 'root',                      # Not used with sqlite3.
        'PASSWORD': '123',                  # Not used with sqlite3.
        'HOST': 'localhost',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}

local_settings.py

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'banco2',                      # Or path to database file if using sqlite3.
        'USER': 'root',                      # Not used with sqlite3.
        'PASSWORD': '123',                  # Not used with sqlite3.
        'HOST': 'localhost',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}

Проблема в том, что local_settings.py не переопределяет settings.py . Что не так?

Answer 1

Вы не можете просто добавить local_settings.py, вам нужно просто импортировать его.

В самом конце вашего settings.py, добавьте это:

try:
    from local_settings import *
except ImportError:
    pass

Блок try / исключением присутствует, поэтому Python просто игнорирует случай, когда вы на самом деле не определили файл local_settings.

Answer 2

Это лучшая практика, я думаю:

• local_settings импорт из settings
• local_settings переопределяет настройки, специфичные для локальной среды, особенно DATABASES, SECRET_KEY, ALLOWED_HOSTS и DEBUG переменные
• передать командам управления django флаг --settings=local_settings

Вы можете реализовать local_settings так:

from settings import *

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'banco2',                      # Or path to database file if using sqlite3.
        'USER': 'root',                      # Not used with sqlite3.
        'PASSWORD': '123',                  # Not used with sqlite3.
        'HOST': 'localhost',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}

Несколько дополнительных ключевых моментов:

• settings.py находится в режиме управления версиями, написанным таким образом, что оно готово для использования участниками
• local_settings.py (или чаще prod_settings.py) НЕ находится в управлении версиями и используется в производстве путем указания --settings=prod_settings или аналогичного.

Если дотронуться до файла стандартных настроек, это также облегчает обновление версии django. Когда вы обновите Django до следующей версии, посмотрите на различие в settings.py и вашем и выполните необходимые действия в зависимости от того, что изменилось. Изменения в значениях по умолчанию могут быть важны, и чем меньше вы прикоснулись к исходному файлу settings.py, тем легче будет заметить изменения в восходящем направлении.

Answer 3

Поскольку тема постоянно обновляется, позвольте мне резюмировать, почему вы, возможно, захотите рассмотреть этот подход:

• тупой файл настроек очень быстр и легко изменяется;особенно в производственной среде.Не требуется Python: любой идиот может подключиться и изменить пароль базы данных в файле, который просто перечисляет имена и значения;особенно по сравнению со сложным файлом настроек Python, содержащим загадочные и опасные имена BIGCAPS.

• приложение settings должно быть полностью отделено от приложения code.Вы можете поместить config.ini за пределы корня репозитория и больше никогда не беспокоиться о том, что выталкивание репо нарушает ваши настройки, или ваши личные настройки загрязняют репо, или этот умный код в вашем settings.py не превращает его в репозиторий в интересах всех остальных..

Это не относится к небольшим проектам, но для более крупных проектов я пришел к выводу, что стратегия local_settings просто не сокращает ее;со временем достаточно прикладного программирования, которое становится трудным для обработки;прежде всего, когда настройки становятся производными и / или зависимыми от кода.Могут быть веские основания для того, чтобы настройки реагировали в соответствии с локальными настройками, что заставляет импорт файла local_settings приближаться к середине settings.py.Я нахожу, что вещи начинают запутываться, когда это происходит.

Мое текущее решение - использовать файл config, я называю его "local.ini".Он содержит только те значения, которые действительно изменяются между развернутыми экземплярами.Нет никакого кода: они являются просто значениями и логическими значениями:

[global]
domain = 127.0.0.1:8000
database_host = 127.0.0.1
database_name = test_database
debug = Yes
google_analytics_id = UA-DEV-1
payments = testing
use_cdn = No

Имея это место, я могу обрабатывать settings.py как любой другой фрагмент кода приложения: настроить его, зарегистрировать и развернутьбез необходимости беспокоиться о тестировании любого кода, который может скрываться в коде Python local_settings.Мой settings.py свободен от условий гонки, которые возникают, когда более поздние настройки зависят от локальных настроек, и я могу включать и выключать функции при написании простого для понимания линейного кода.Больше не нужно торопливо настраивать файл local_settings, когда я забыл добавить какое-то новое значение, и больше нет файлов daves_local_settings.py и bobs_local_settings.py, попадающих в хранилище.

from ConfigParser import RawConfigParser
parser = RawConfigParser()

APPLICATION_ROOT = path.abspath(path.dirname(__file__))
parser.readfp(open(path.join(APPLICATION_ROOT, 'local.ini')))

# simple variables
DATABASE_HOST = parser.get('global', 'database_host')
DATABASE_NAME = parser.get('global', 'database_name')

# interdependencies
from version import get_cdn_version
CDN = 'd99phdomw5k72k.cloudfront.net'
if parser.getboolean('global', 'use_cdn'):
    STATIC_URL = '/{}/static/{}/'.format(CDN, get_cdn_version())
else:
    STATIC_URL = '/static/'


# switches
payments = parser.get('global', 'payments')
if payments == 'testing':
    PAYMENT_GATEWAY_ENDPOINT = 'https://api.sandbox.gateway.com'
else:
    PAYMENT_GATEWAY_ENDPOINT = 'https://api.live.gateway.com'

Если вы встретите BOFH , как у меня однажды, он был особенно взволнован возможностью вставить local.ini в каталог /etc как /etc/ourapp.ini и, таким образом, сохранить сам каталог приложения в чистом экспорте репозитория.Конечно, вы можете сделать это с помощью local_settings.py, но последнее, что он хотел сделать, - это возиться с кодом Python.Простой файл конфигурации, который он мог обработать.

Answer 4

Я сохранил копию __local_settings.py:

• local_settings.py игнорируется в управлении версиями, но не __local_settings.py
• update README.md для информированияКоманда о том, как установить: cp {__,}local_settings.py (которые делают копию для своих local_settings)

В прошлом

Я использовал для импорта этих настроек.

# settings.py
DATABASE = {...}

try:
    from .local_settings import *
except ImportError:
    pass

сейчас

Я просто импортирую настройки из local_settings.py.

И с помощью следующей команды: python manage.py runserver --settings=<proj>.local_settings.

# local_settings.py & __local_settings.py
from .settings import *

DATABASE = {...}

И, поскольку я обычно не взаимодействую напрямую с manage.py, потому что некоторые параметры мне явно необходимы (например, address:port).Поэтому я помещаю все эти команды в мой Makefile.

Например, вот мой Makefile:

run:
    python manage.py runserver 0.0.0.0:8000 --settings=<proj>.local_settings

sh:
    python manage.py shell_plus --settings=<proj>.local_settings

dep:
    npm install
    pip install -r requirements.txt

Таким образом:

make dep
make sh 
make run

Заключение

При условии, что вы не используете Makefile в качестве рабочего процесса, тогда вы можете использовать более ранний метод, но если вы используете makefile, то я считаю, что лучше быть более явным в вашемMakefile.

Answer 5

Перед запуском сервера сделайте

export DJANGO_SETTINGS_MODULE=your_app_name.local_settings где your_app_name должно быть заменено именем вашего приложения. И не забудьте сделать

from settings import *

в вашем файле local_settings.py

Answer 6

Еще один подход заключается в использовании python-dotenv и переменных среды для настройки параметров для различных сред.

Создайте файл .env рядом с вашим settings.py:

# .env
SECRET_KEY=your-secret-key
DATABASE_PASSWORD=your-database-password

Добавьте следующий код к вашему settings.py:

# settings.py
from dotenv import load_dotenv
load_dotenv()

# OR, explicitly providing path to '.env'
from pathlib import Path  # python 3.4+
env_path = Path('.') / '.env'
load_dotenv(dotenv_path=env_path)

На этомточка, проанализированные ключи / значения из файла .env присутствуют как переменные среды, и к ним можно легко получить доступ через os.getenv():

# settings.py
import os
SECRET_KEY = os.getenv('SECRET_KEY')
DATABASE_PASSWORD = os.getenv('DATABASE_PASSWORD')   

Answer 7

Добавьте это в конец файла settings.py

try:
    from .local_settings import *
except ImportError:
    pass

и создайте файл local_settings.py с вашими новыми настройками, например

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'banco2',                      # Or path to database file if using sqlite3.
        'USER': 'root',                      # Not used with sqlite3.
        'PASSWORD': '123',                  # Not used with sqlite3.
        'HOST': 'localhost',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}

Answer 8

Я нашел подобное решение.Это моя конфигурация для этого случая:

settings.py:

DEBUG = False

try:
    from local_settings import *

except ImportError:
    pass

if DEBUG is False:
    ALLOWED_HOSTS = ['sth.com']
    DATABASES = {
        ....
    }

local_settings.py:

from settings import *
ALLOWED_HOSTS = ['*']
DEBUG = True
DATABASES = {
    ...
}