search

paladin223 / django

0 stars 0 forks source link

Доработать момент с переменными окружения #6

Closed drowsycoder closed 1 year ago

drowsycoder commented 1 year ago

В .env стоит поместить SECRET_KEY, DEBUG и ALLOWED_HOSTS. Данные в сеттингс забирать оттуда

При этом не надо заставлять пользователя с нуля создавать что-то, без чего проект не заработает Предварительно намекну: допустим, я решил установить проект с нуля. При этом, например, пока DEBUG не задан и если проект не знает, где это значение искать, строчка DEBUG = os.getenv("DEBUG") вернёт False. А это автоматически приведет к ошибке, что не прописаны ALLOWED_HOSTS. И всё накрылось в итоге

В идеале всегда должен быть спокойный запуск runserver как с .env-файлом, как с переменными в настройках проекта на гитхабе, так и если вообще если нет ни того, ни другого (проверить!!!). Просто от этого может зависеть debug-режим это или нет (а в перспективе и к другим параметрам может быть привязка, например, к тем же базам данных).

Как вариант, удобно зайти в доку какого-то модуля и взять оттуда что-то аккуратное типа этого:

import environ

env = environ.Env(
    # Set casting, default value
    DEBUG=(bool, True),
    SECRET_KEY=(str, 'dummy-key'),
    ALLOWED_HOSTS=(list, ['*']),
    <...>
)

BASE_DIR = Path(__file__).resolve().parent.parent

environ.Env.read_env(BASE_DIR / '.env')

DEBUG = env('DEBUG')

<...>

Ознакомься с конструкциями для settings.py типа SECRET_KEY = os.environ.get('SECRET_KEY', 'any-other-dummy-key') и DEBUG = os.environ.get('DEBUG', True), про os.getenv, про load_dotenv, что для этого импортировать и как использовать. Такого дополнения будет достаточно. Дополнительно почитай про варианты хранения переменных окружения и как их прятать (в т.ч. про обработку случаев хранения этих переменных в настройках проекта в гитхабе). Выше есть подвох: строки из .env читаются как строки. Для булевых это надо обработать дополнительно или выбрать из указанных нужную умную функцию, которая сама всё сделает, а то какая-нибудь строка пойдёт как тру

Думаю, будет неплохим заданием проверить это на практике. Да и в принципе всё целиком Во-первых, здесь немного, так что даже ручное тестирование сойдёт :) Во-вторых, само понимание реакции джанги на настройку DEBUG будет полезно

Запустил без .env, когда в сеттингс дебаг=тру Запустил без .env, когда в сеттингс дебаг=фолс Запустил с .env, когда там дебаг=тру и когда дебаг=фолс, при этом противоположно значению дебаг в сеттингс Запустил с .env, когда там дебаг это число/строка (помним про особенности их приведения к булевым и подставляем варианты), при этом противоположно значению дебаг в сеттингс

И смотрим, как ведёт себя главная: поведение должно быть идентично прописыванию настройки в сеттингс А при запуске не должно быть жёлтых страниц с техническими ошибками и кучей кода

Заодно чтобы было понимание, когда начинает требоваться ALLOWED_HOSTS (они тоже читаются из энва как строка, сплитятся обычно по запятой без пробела)

Но и это не всё

Вот разместили мы что-то в .env А как он должен выглядеть? Давай поместим пример этого файла в репо и назовём как-то типа example_config.env Предложим команду, как его можно использовать (cp example_config.env .env), чтобы пользователь для простого теста нашего проекта не создавал ничего вручную, и упомянем, что при необходимости содержимое .env можно настроить под себя

paladin223 commented 1 year ago

image

paladin223 commented 1 year ago

Я не понял про

Вот разместили мы что-то в .env А как он должен выглядеть? Давай поместим пример этого файла в репо и назовём как-то типа example_config.env Предложим команду, как его можно использовать (cp example_config.env .env), чтобы пользователь для простого теста нашего проекта не создавал ничего вручную, и упомянем, что при необходимости содержимое .env можно настроить под себя

Нужно ли мне это делать или это как доп. задание?

drowsycoder commented 1 year ago

Давай. Поместим. Пример этого файла. В репо. И назовём его example_config.env. Или example.env. Или .env.example. Да не особо важно, главное плюс-минус красиво и логично, сам выбери.

В ридми. Пропишем пользователю. Команду. Как этот файл можно использовать. Например, cp example_config.env .env (может отличаться для линуксов, там же всякие рекурсивные вещи в директориях происходят, или нет, сам разберись). Чтобы пользователь. Не создавал ничего вручную. И упомянем. Там же, в ридми. Что при необходимости содержимое .env можно настроить под себя.

drowsycoder commented 1 year ago

В тексте issue упоминал:

Выше есть подвох: строки из .env читаются как строки

Так что кавычки там не нужны

Для учебных целей в сеттингс ALLOWED_HOSTS пока можно указать (в рамках первого задания) ['*'] И тем же надо будет заморочиться в энве. Ты работаешь у себя? Можешь поставить те самые 127.0.0.1,localhost. Кавычки не нужны (для всех указанных тобой значений удали), по умолчанию там строки

drowsycoder commented 1 year ago 
if os.getenv("DEBUG") in ["False", "0"]:
    DEBUG = False

А если написано "no" или "n"? Их тоже можно обработать :)

in ["False", "0"]

Если нет необходимости, кортеж лучше списка

Но в целом неплохо. В будущем такую обработку можно вынести для красоты в отдельную функцию

drowsycoder commented 1 year ago

Не доработано

Обработка DEBUG так себе Вообще, можно вынести после импортов функцию, которая будет проверять поступившее значение на значение из списка "типа включаем значение" (1, True, t, yes, y,..) Она бы у нас ещё и вдопнике понадобилась

А для ALLOWED_HOSTS в settings можно пока поместить '*', а вот в .env - 127.0.0.1,localhost

drowsycoder commented 1 year ago

Про ALLOWED_HOSTS не обратил внимание, видимо

А ещё в .env пробелы не нужны (смотрим тестовый энв-файл в репо)