Mam projekt Heroku, który używa zmiennych środowiskowych do uzyskania swojej konfiguracji, ale najpierw używam virtualenv do testowania mojej aplikacji lokalnie.

Czy istnieje sposób na ustawienie zmiennych środowiskowych zdefiniowanych na maszynie zdalnej w virtualenv?

Aktualizacja

Od 17 maja 2017 plik README autoenv stwierdza, że direnv jest prawdopodobnie lepszą opcją i sugeruje, że autoenv nie jest już utrzymywane.

Stara odpowiedź

Napisałem autoenv, aby zrobić dokładnie to:

https://github.com/kennethreitz/autoenv

Jeśli używasz virtualenvwrapper (bardzo polecam to zrobić), możesz zdefiniować różne hooki (preactivate, postactivate, preactivate, postdeactivate) przy użyciu skryptów o tych samych nazwach w $VIRTUAL_ENV/bin/. Potrzebujesz haka po aktywacji.

$ 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

Jeśli chcesz zachować tę konfigurację w katalogu projektu, po prostu utwórz łącze symboliczne z katalogu projektu do $VIRTUAL_ENV/bin/postactivate.

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

Możesz nawet zautomatyzować tworzenie dowiązań symbolicznych za każdym razem, gdy używasz mkvirtualenv .

Czyszczenie po dezaktywacji

Pamiętaj, że to nie posprząta po sobie. Po dezaktywacji virtualenv zmienna środowiskowa pozostanie. Aby wyczyścić symetrycznie, możesz dodać do $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

Pamiętaj, że jeśli używasz tego dla zmiennych środowiskowych, które mogą już być ustawione w twoim środowisku, to nieustawienie spowoduje ich całkowite wyłączenie przy opuszczaniu virtualenv. Więc jeśli jest to w ogóle prawdopodobne, możesz tymczasowo nagrać poprzednią wartość, a następnie odczytać ją ponownie po dezaktywacji.

Ustawiać:

$ 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

Test:

$ echo $SOME_VAR
banana

$ workon myenv

$ echo $SOME_VAR
apple

$ deactivate

$ echo $SOME_VAR
banana

Możesz spróbować:

export ENVVAR=value

w virtualenv_root / bin / activ. Zasadniczo skrypt aktywacyjny jest wykonywany, gdy zaczynasz używać virtualenv, dzięki czemu możesz tam umieścić wszystkie swoje ustawienia.

Używając tylko virtualenv (bez virtualenvwrapper ), ustawianie zmiennych środowiskowych jest łatwe za pomocą activateskryptu, który pozyskujesz w celu aktywacji virtualenv.

Biegać:

nano YOUR_ENV/bin/activate

Dodaj zmienne środowiskowe na końcu pliku w następujący sposób:

export KEY=VALUE

Możesz także ustawić podobny punkt zaczepienia, aby anulować ustawienie zmiennej środowiskowej, zgodnie z sugestią Danilo Bargena w jego świetnej odpowiedzi powyżej, jeśli potrzebujesz.

Chociaż jest tutaj wiele fajnych odpowiedzi, nie widziałem opublikowanego rozwiązania, które obejmuje usuwanie zmiennych środowiskowych przy dezaktywacji i nie wymaga dodatkowych bibliotek poza tym virtualenv, więc oto moje rozwiązanie, które polega tylko na edycji / bin / aktywowaniu za pomocą zmienne MY_SERVER_NAMEi MY_DATABASE_URLjako przykłady:

W skrypcie aktywacyjnym powinna znajdować się definicja dezaktywacji, a na końcu chcesz usunąć ustawienia zmiennych:

deactivate () {
    ...

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

Następnie na końcu skryptu aktywacji ustaw zmienne:

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

W ten sposób nie musisz instalować niczego innego, aby działał, i nie kończy się na tym, że zmienne pozostają po deactivateuruchomieniu virtualenv.

Lokalnie w ramach virtualenv można to przetestować na dwa sposoby. Pierwsza to narzędzie, które jest instalowane za pośrednictwem paska narzędzi Heroku (https://toolbelt.heroku.com/). Narzędziem jest brygadzista. Wyeksportuje wszystkie zmienne środowiskowe, które są przechowywane lokalnie w pliku .env, a następnie uruchomi procesy aplikacji w pliku Procfile.

Drugim sposobem, jeśli szukasz lżejszego podejścia, jest posiadanie pliku .env lokalnie, a następnie uruchomienie:

export $(cat .env)

Zainstaluj autoenv albo przez

$ pip install autoenv

(lub)

$ brew install autoenv

Następnie utwórz .envplik w folderze projektu virtualenv

$ echo "source bin/activate" > .env

Teraz wszystko działa dobrze.

Jeśli korzystasz już z Heroku, rozważ uruchomienie serwera przez Foreman . Obsługuje .envplik, który jest po prostu listą wierszy, KEY=VALktóre zostaną wyeksportowane do Twojej aplikacji przed uruchomieniem.

Innym sposobem na zrobienie tego, który został zaprojektowany dla django, ale powinien działać w większości ustawień, jest użycie django-dotenv.

• Oryginał - https://github.com/jacobian/django-dotenv
• Bardziej w pełni funkcjonalny fork - https://github.com/tedtieken/django-dotenv-rw (napisałem to, aby móc ustawić moje zdalne ustawienia .env na webfaction z mojego lokalnego wiersza poleceń, heroku mnie zepsuło)

Aby aktywować virtualenv w envkatalogu i wyeksportować używane zmienne envinroment .env:

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