it-swarm.com.ru

установка переменной среды в virtualenv

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

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

134
Mahmoud Hossam

Обновление

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

Старый ответ

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

https://github.com/kennethreitz/autoenv

95
Kenneth Reitz

Если вы используете 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
274
Danilo Bargen

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

export ENVVAR=value

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

34
kgr

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

Бежать:

nano YOUR_ENV/bin/activate

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

export KEY=VALUE

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

30
Nagasaki45

Хотя здесь есть много хороших ответов, я не видел опубликованного решения, которое включает в себя сброс переменных среды при деактивации и не требует дополнительных библиотек, кроме 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>"

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

23
TheLetterN

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

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

export $(cat .env)
17
CraigKerstiens

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

$ pip install autoenv

(или же)

$ brew install autoenv

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

$ echo "source bin/activate" > .env

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

7
Fizer Khan

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

4
Ted

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

3
Michael Mior

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

# my_env.sh
export MY_VENV=true
bash

В ~/.bashrc положить:

# .bashrc
if [ "$MY_VENV" = "true" ]; then
    source ~/.pyenv/bin/activate
    export PYTHONPATH=/some/local/libs
    cd /project/path
    PS1='(my_venv:\w)$ '
fi

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

0
Zach Thompson