У меня есть проект Heroku, который использует переменные среды, чтобы получить его конфигурацию, но я использую virtualenv, чтобы сначала протестировать свое приложение локально.

Есть ли способ установить переменные среды, определенные на удаленном компьютере внутри virtualenv?

Обновить

По состоянию на 17 мая 2017 года README autoenv утверждает, что direnv , вероятно, является лучшим вариантом и подразумевает, что autoenv больше не поддерживается.

Старый ответ

Я написал autoenv, чтобы сделать именно это:

https://github.com/kennethreitz/autoenv

Если вы используете virtualenvwrapper (я настоятельно рекомендую это сделать), вы можете определить различные хуки (преактивировать, постактивировать, предактивировать, постдезактивировать), используя скрипты с одинаковыми именами $VIRTUAL_ENV/bin/. Вам нужен постактивированный крюк.

$ workon myvenv

$ cat $VIRTUAL_ENV/bin/postactivate
#!/bin/bash
# This hook is run after this virtualenv is activated.
export DJANGO_DEBUG=True
export S3_KEY=mykey
export S3_SECRET=mysecret

$ echo $DJANGO_DEBUG
True

Если вы хотите сохранить эту конфигурацию в каталоге вашего проекта, просто создайте символическую ссылку из каталога вашего проекта на $VIRTUAL_ENV/bin/postactivate.

$ rm $VIRTUAL_ENV/bin/postactivate
$ ln -s .env/postactivate $VIRTUAL_ENV/bin/postactivate

Вы даже можете автоматизировать создание символических ссылок каждый раз, когда используете mkvirtualenv .

Очистка при деактивации

Помните, что это не будет убирать за собой. Когда вы деактивируете virtualenv, переменная окружения сохранится. Чтобы очистить симметрично вы можете добавить в $VIRTUAL_ENV/bin/predeactivate.

$ cat $VIRTUAL_ENV/bin/predeactivate
#!/bin/bash
# This hook is run before this virtualenv is deactivated.
unset DJANGO_DEBUG

$ deactivate

$ echo $DJANGO_DEBUG

Помните, что если использовать это для переменных среды, которые уже могут быть установлены в вашей среде, то неустановленные значения приведут к их полной отмене при выходе из virtualenv. Так что, если это вообще возможно, вы можете записать предыдущее значение где-то временно, а затем прочитать его обратно при деактивации.

Настроить:

$ cat $VIRTUAL_ENV/bin/postactivate
#!/bin/bash
# This hook is run after this virtualenv is activated.
if [[ -n $SOME_VAR ]]
then
    export SOME_VAR_BACKUP=$SOME_VAR
fi
export SOME_VAR=apple

$ cat $VIRTUAL_ENV/bin/predeactivate
#!/bin/bash
# This hook is run before this virtualenv is deactivated.
if [[ -n $SOME_VAR_BACKUP ]]
then
    export SOME_VAR=$SOME_VAR_BACKUP
    unset SOME_VAR_BACKUP
else
    unset SOME_VAR
fi

Тест:

$ echo $SOME_VAR
banana

$ workon myenv

$ echo $SOME_VAR
apple

$ deactivate

$ echo $SOME_VAR
banana

Вы можете попробовать:

export ENVVAR=value

в virtualenv_root / bin / activ. По сути, сценарий активации - это то, что выполняется, когда вы начинаете использовать virtualenv, чтобы вы могли поместить туда все свои настройки.

Используя только virtualenv (без virtualenvwrapper ), установить переменные среды легко с помощью activateсценария, который вы используете для активации virtualenv.

Бегать:

nano YOUR_ENV/bin/activate

Добавьте переменные окружения в конец файла следующим образом:

export KEY=VALUE

Вы также можете установить аналогичный хук, чтобы сбросить переменную окружения, как это было предложено Данило Баргеном в его великолепном ответе выше, если вам нужно.

Хотя здесь есть много хороших ответов, я не видел опубликованного решения, которое включает в себя сброс переменных среды при деактивации и не требует дополнительных библиотек virtualenv, поэтому вот мое решение, которое просто включает редактирование / bin / activ с использованием переменные MY_SERVER_NAMEи в MY_DATABASE_URLкачестве примеров:

В сценарии активации должно быть определение деактивации, и вы хотите сбросить переменные в конце его:

deactivate () {
    ...

    # Unset My Server's variables
    unset MY_SERVER_NAME
    unset MY_DATABASE_URL
}

Затем в конце сценария активации установите переменные:

# Set My Server's variables
export MY_SERVER_NAME="<domain for My Server>"
export MY_DATABASE_URL="<url for database>"

Таким образом, вам не нужно устанавливать что-либо еще, чтобы заставить его работать, и вы не останетесь с переменными, оставшимися, когда станете deactivatevirtualenv.

Локально внутри virtualenv есть два метода, которые вы можете использовать для проверки этого. Первый - это инструмент, который устанавливается через инструментальный пояс Heroku (https://toolbelt.heroku.com/). Инструмент бригадир. Он будет экспортировать все переменные среды, которые хранятся в файле .env локально, а затем запустить процессы приложения в вашем Procfile.

Второй способ, если вы ищете более легкий подход, - это локально создать файл .env и запустить:

export $(cat .env)

Установите autoenv либо

$ pip install autoenv

(или)

$ brew install autoenv

А затем создайте .envфайл в папке вашего проекта virtualenv

$ echo "source bin/activate" > .env

Теперь все работает отлично.

Если вы уже используете Heroku, рассмотрите возможность запуска вашего сервера через Foreman . Он поддерживает .envфайл, представляющий собой просто список строк, KEY=VALкоторые будут экспортированы в ваше приложение до его запуска.

Другой способ сделать это, который разработан для django, но должен работать в большинстве настроек, это использовать django-dotenv.

• Оригинал - https://github.com/jacobian/django-dotenv
• Более полнофункциональный fork- https: //github.com/tedtieken/django-dotenv-rw (я написал это, чтобы иметь возможность устанавливать мои удаленные настройки .env на webfaction из моей локальной командной строки, heroku избаловал меня)

Чтобы активировать virtualenv в envкаталоге и экспортировать переменные среды, хранящиеся в .envиспользовании:

source env/bin/activate && set -a; source .env; set +a