У мене є проект 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 / activate. В основному, сценарій активації - це те, що виконується, коли ви починаєте використовувати virtualenv, щоб ви могли помістити туди всі свої налаштування.

Використовуючи лише virtualenv (без virtualenvwrapper ), налаштовувати змінні середовища легко через activateсценарій, який ви шукаєте, щоб активувати virtualenv.

Виконати:

nano YOUR_ENV/bin/activate

Додайте змінні середовища в кінець файлу так:

export KEY=VALUE

Ви також можете встановити подібний гачок, щоб скинути змінну середовища, як запропонував Данило Барген у своїй чудовій відповіді вище, якщо вам потрібно.

Хоча тут є багато приємних відповідей, я не побачив рішення, яке включає в себе нестабільні змінні середовища для деактивації і не потребує додаткових бібліотек virtualenv, тому ось моє рішення, яке включає лише редагування / бін / активацію, використовуючи змінні 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 для веб-роботи з мого локального командного рядка, heroku зіпсував мене)

Щоб активувати virtualenv в envкаталозі та експортувати змінні середовища, що зберігаються у .envвикористанні:

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