Ответ 1

Обновить

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

Старый ответ

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

https://github.com/kennethreitz/autoenv

Ответ 2

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

$ 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

Ответ 3

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

export ENVVAR=value

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

Ответ 4

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

Run:

nano YOUR_ENV/bin/activate

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

export KEY=VALUE

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

Ответ 5

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

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

deactivate () {
    ...

    # Unset My Server variables
    unset MY_SERVER_NAME
    unset MY_DATABASE_URL
}

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

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

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

Ответ 6

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

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

export $(cat .env)

Ответ 7

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

$ pip install autoenv

(или)

$ brew install autoenv

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

$ echo "source bin/activate" > .env

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

# 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

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