festlegen einer Umgebungsvariable in virtualenv

Falls Sie virtualenvwrapper verwenden (ich empfehle das sehr), können Sie verschiedene Hooks definieren (voraktivieren, nachaktivieren, voraktivieren, nachaufaktivieren), indem Sie die Skripts verwenden, die in $VIRTUAL_ENV/bin/ denselben Namen haben. Sie benötigen den Postactivate-Hook.

$ 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

Wenn Sie diese Konfiguration in Ihrem Projektverzeichnis behalten möchten, erstellen Sie einfach einen Symlink von Ihrem Projektverzeichnis zu $VIRTUAL_ENV/bin/postactivate.

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

Sie können sogar die Erstellung der Symlinks automatisieren jedes Mal, wenn Sie mkvirtualenv verwenden.

Aufräumen beim deaktivieren

Denken Sie daran, dass dies nicht nach sich selbst aufräumt. Wenn Sie die Virtualenv deaktivieren, bleibt die Umgebungsvariable erhalten. Zum symmetrischen Aufräumen können Sie $VIRTUAL_ENV/bin/predeactivate hinzufügen.

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

$ deactivate

$ echo $Django_DEBUG

Wenn Sie dies für Umgebungsvariablen verwenden, die möglicherweise bereits in Ihrer Umgebung festgelegt sind, führt das Aufheben der Einstellung dazu, dass diese beim Verlassen der virtuellen Umgebung vollständig zurückgesetzt werden. Wenn dies wahrscheinlich ist, können Sie den vorherigen Wert an einem temporären Ort aufzeichnen und dann beim Deaktivieren wieder einlesen.

Konfiguration:

$ 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

Prüfung:

$ echo $SOME_VAR
banana

$ workon myenv

$ echo $SOME_VAR
Apple

$ deactivate

$ echo $SOME_VAR
banana

Du könntest es versuchen:

export ENVVAR=value

in virtualenv_root/bin/enable . Im Wesentlichen wird das Aktivierungsskript ausgeführt, wenn Sie die virtualenv verwenden, sodass Sie Ihre gesamte Anpassung dort einfügen können.

Wenn Sie nur virtualenv (ohne virtualenvwrapper ) verwenden, können Sie Umgebungsvariablen ganz einfach über das Skript activate einstellen, das Sie verwenden, um die virtualenv zu aktivieren.

Lauf:

nano YOUR_ENV/bin/activate

Fügen Sie die Umgebungsvariablen wie folgt am Ende der Datei hinzu:

export KEY=VALUE

Sie können auch einen ähnlichen Haken setzen, um die Umgebungsvariable zu deaktivieren, wie von Danilo Bargen in seiner tollen Antwort oben vorgeschlagen, wenn Sie dies benötigen.

Es gibt zwar viele schöne Antworten, aber ich habe keine Lösung gesehen, die sowohl das Deaktivieren von Umgebungsvariablen beim Deaktivieren beinhaltet als auch zusätzliche Bibliotheken neben virtualenv. Daher ist hier meine Lösung, die nur das Editieren/bin/enable beinhaltet die Variablen MY_SERVER_NAME und MY_DATABASE_URL als Beispiele:

Es sollte eine Definition für das Deaktivieren im Aktivierungsskript vorhanden sein, und Sie möchten Ihre Variablen am Ende deaktivieren:

deactivate () {
    ...

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

Stellen Sie dann am Ende des Aktivierungsskripts die Variablen ein:

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

Auf diese Weise müssen Sie nichts anderes installieren, damit es funktioniert, und Sie werden nicht mit den Variablen enden, die übrig bleiben, wenn Sie die virtuelle Variable deactivate verwenden.

In einer virtuellen Umgebung gibt es zwei Methoden, mit denen Sie dies testen können. Das erste ist ein Tool, das über den Heroku-Toolbelt (https://toolbelt.heroku.com/) installiert wird. Das Werkzeug ist Vorarbeiter. Es werden alle Umgebungsvariablen, die lokal in einer .env-Datei gespeichert sind, exportiert und anschließend App-Prozesse innerhalb Ihrer Procfile ausgeführt.

Wenn Sie nach einem einfacheren Ansatz suchen, können Sie eine .env-Datei lokal haben und dann ausführen:

export $(cat .env)

Installiere autoenv entweder per

$ pip install autoenv

(oder)

$ brew install autoenv

Erstellen Sie dann die .env-Datei in Ihrem Virtualenv-Projektordner

$ echo "source bin/activate" > .env

Jetzt funktioniert alles gut.

Eine andere Möglichkeit, die für Django entwickelt wurde, sollte aber in den meisten Umgebungen funktionieren, ist Django-dotenv. 

• Original - https://github.com/jacobian/Django-dotenv
• Vollständig ausgestattetes Fork- https://github.com/tedtieken/Django-dotenv-rw (Ich schrieb dies, um meine Remote-ENV-Einstellungen von meiner lokalen Befehlszeile aus auf Webfaction einstellen zu können.

Wenn Sie Heroku bereits verwenden, sollten Sie Ihren Server über Foreman ausführen. Es unterstützt eine .env-Datei, bei der es sich einfach um eine Liste von Zeilen mit KEY=VAL handelt, die vor der Ausführung in Ihre App exportiert werden.

Ein anderer Ansatz besteht darin, eine Bash-Shell mit einem in ihr laufenden Venv zu formen. Führen Sie eine ausführbare Datei aus, die Folgendes enthält:

# my_env.sh
export MY_VENV=true
bash

In ~/.bashrc setze:

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

Durch das Verlassen der gegabelten Shell wird die ursprüngliche Umgebung wiederhergestellt, und Sie müssen keine Deaktivierung ausführen.