AndreyPhys Oct 23 2019 at 12:12

Переменные окружения для Python проектов

4 min

150K

Python*

From sandbox

+15

Comments 12

gnomeby Oct 23 2019 at 13:12

Насколько я помню апач при запуске с запароленным сертификатом спрашивает пароль интерактивно прямо во время старта. То есть даже в некоторых местах переменным окружения не доверяют.

TSchmidt Oct 23 2019 at 13:41

.gitignor

Всё таки ".gitignore", мне кажется.

AndreyPhys Oct 23 2019 at 13:47

Точно.
Спасибо, исправил.

webdevium Oct 23 2019 at 13:49

Стоит обратить внимание на dotenv-linter

mrBuG Oct 23 2019 at 13:58

Есть ещё один вариант — управлять виртуальным окружением через pipenv. Оно уже из коробки поддерживает .env файлы и выставляет оттуда переменные окружения при выполнении команд pipenv shell / pipenv run. Остается лишь обратиться к ним из проекта любым удобным способом.

kostyaten Oct 23 2019 at 14:05

Вопрос, чем плохо иметь в /etc/environment
export KEY=«Ключ»
И в питоне получать os.environ.get('KEY') ???

AndreyPhys Oct 23 2019 at 14:19

Хранить переменные окружения в /etc/environment плохо тем, что это требует наличия прав суперпользователя и при таком подходе трудно разделять переменные окружения для разных проектов.
Кроме того, иногда нужно задавать переменные окружения до запуска питона.

eternal_why Oct 23 2019 at 20:50

Мне единственному кажется странной идея использовать библиотеки для загрузки в окружение нежелательных к сохранению в файлы переменных из, опаньки, сохранённых файлов?.. :)

asergrisa Nov 5 2019 at 16:30

Эти переменные нежелательно держать в репозитарии, но локально можно

-1

dmytrohoi Oct 24 2019 at 02:37

Для полноты картины стоит упомянуть virtualenvwrapper под virtualenv и, как указал mrBug, мощную Pipenv.

Приходилось работать с последней, легко начать работу и оперировать зависимостями, ресурсами и т.д.

baldr Oct 25 2019 at 17:30

Да, действительно, наблюдается некоторая непоследовательность:
Хранить параметры в файле плохо, поэтому давайте будем хранить в переменных окружения, которые запишем в файл. И для этого нам еще нужны библиотеки сторонние!

Вдобавок, если нам потребуется, например, группировать переменные, то, простите — только плоская структура:
AWS_ACCESS_KEY/AWS_SECRET_KEY — это еще просто.

Как вы, например, зададите параметры подключения к базам для Django (settings.DATABASES)?

Я лично использую YAML-файлики, которые перезаписывают все дефолтные переменные. Файлы храню в /usr/local/etc — но это уже предпочтения.

Очень не рекомендую хранить в папке с проектом ничего локально-зависимого. Пример: для отладки я очень часто синхронизирую код в папке с проектом на удаленный сервер с помощью rsync (lsyncd). Если там лежит какой-нибудь local_settings.yaml для моей локальной системы — он тоже будет отправлен на сервер, хотя там будет нужен свой. Ну а сколько историй о том, как кто-то по ошибке закоммитил локальный конфиг…

webdevium Oct 25 2019 at 19:08

Историй много таких, конечно. Потому и додумались, что в проекте есть только .env.example (любое другое имя), как набор возможных параметров и примеры их наполнения. А вот нужный "локальный" .env обязательно в .gitignore. Естественно, этот файл никогда не попадет на сервер, пока вы не начнете использовать для деплоя НЕ git.
Но даже для Вашего случая с rsync есть отличное решение:

rsync --filter=":- .gitignore" ...

Show the best of all time