web-dev-qa-db-fra.com

définir une variable d'environnement dans virtualenv

J'ai un projet Heroku qui utilise des variables d'environnement pour obtenir sa configuration, mais j'utilise virtualenv pour tester mon application localement.

Est-il possible de définir les variables d'environnement définies sur la machine distante dans virtualenv?

pythonherokuenvironment-variablesvirtualenv
134
Mahmoud Hossam

Mettre à jour

Depuis le 17 mai 2017, le README de autoenv indique que direnv est probablement la meilleure option et implique que ce dernier n'est plus maintenu.

Ancienne réponse

J'ai écrit autoenv pour faire exactement ceci:

https://github.com/kennethreitz/autoenv

95
Kenneth Reitz

Si vous utilisez virtualenvwrapper (je vous le recommande vivement), vous pouvez définir différents hooks (préactiver, postactiver, pré-activer, post-désactiver) à l'aide des scripts du même nom dans $VIRTUAL_ENV/bin/. Vous avez besoin du hook 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

Si vous souhaitez conserver cette configuration dans votre répertoire de projet, créez simplement un lien symbolique à partir de votre répertoire de projet vers $VIRTUAL_ENV/bin/postactivate.

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

Vous pouvez même automatiser la création des liens symboliques à chaque fois que vous utilisez mkvirtualenv.

Nettoyage sur désactiver

Rappelez-vous que cela ne va pas nettoyer après lui-même. Lorsque vous désactivez virtualenv, la variable d'environnement persistera. Pour nettoyer de manière symétrique, vous pouvez ajouter à $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

N'oubliez pas que si vous utilisez ceci pour des variables d'environnement déjà définies dans votre environnement, les valeurs non définies entraîneront leur suppression complète à la sortie de virtualenv. Donc, si cela est probable, vous pouvez enregistrer la valeur précédente temporairement, puis la relire à la désactivation.

Installer:

$ 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

Tester:

$ echo $SOME_VAR
banana

$ workon myenv

$ echo $SOME_VAR
Apple

$ deactivate

$ echo $SOME_VAR
banana
274
Danilo Bargen

Tu pourrais essayer:

export ENVVAR=value

dans virtualenv_root/bin/activate . En gros, le script activate est exécuté lorsque vous commencez à utiliser virtualenv afin que vous puissiez y mettre toute votre personnalisation.

34
kgr

En utilisant uniquement virtualenv (sans virtualenvwrapper ), il est facile de définir des variables d'environnement grâce au script activate que vous recherchez pour activer le virtualenv.

Courir:

nano YOUR_ENV/bin/activate

Ajoutez les variables d’environnement à la fin du fichier comme ceci:

export KEY=VALUE

Vous pouvez également définir un crochet similaire pour désactiver la variable d'environnement, comme suggéré par Danilo Bargen dans sa réponse géniale ci-dessus si vous en avez besoin.

30
Nagasaki45

Bien qu'il y ait beaucoup de bonnes réponses ici, je n'ai pas vu de solution publiée qui inclut toutes les deux des variables d'environnement non définies à la désactivation et ne nécessitant pas de bibliothèques supplémentaires au-delà de virtualenv, voici donc ma solution qui implique uniquement l'édition/bin/activate, les variables MY_SERVER_NAME et MY_DATABASE_URL à titre d'exemple:

Il devrait y avoir une définition pour désactiver dans le script d'activation, et vous voulez désélectionner vos variables à la fin de celle-ci:

deactivate () {
    ...

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

Ensuite, à la fin du script d'activation, définissez les variables:

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

De cette façon, vous n'avez rien d'autre à installer pour le faire fonctionner, et vous ne vous retrouverez pas avec les variables laissées lorsque vous deactivate le virtualenv.

23
TheLetterN

Localement, dans virtualenv, vous pouvez utiliser deux méthodes pour le tester. Le premier est un outil installé via la Herbu toolbelt (https://toolbelt.heroku.com/). L'outil est contremaître. Il exportera toutes les variables d'environnement stockées dans un fichier .env localement, puis exécutera des processus d'application dans votre fichier Procfile.

La deuxième façon, si vous recherchez une approche plus légère, est d’avoir un fichier .env en local puis de le lancer:

export $(cat .env)
17
CraigKerstiens

Installez autoenv soit par

$ pip install autoenv

(ou)

$ brew install autoenv

Et créez ensuite le fichier .env dans votre dossier de projet virtualenv

$ echo "source bin/activate" > .env

Maintenant tout fonctionne bien.

7
Fizer Khan

Une autre façon de le faire, conçue pour Django, mais devrait fonctionner dans la plupart des contextes, consiste à utiliser Django-dotenv. 

4
Ted

Si vous utilisez déjà Heroku, songez à utiliser votre serveur via Foreman . Il prend en charge un fichier .env qui est simplement une liste de lignes avec KEY=VAL qui sera exporté vers votre application avant son exécution.

3
Michael Mior

Une autre approche consiste à bifurquer une coquille avec une balle en mouvement à l’intérieur. Lancer un exécutable contenant:

# my_env.sh
export MY_VENV=true
bash

Dans ~/.bashrc put:

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

Quitter le shell créé restaure l'environnement d'origine et vous n'avez pas besoin de lancer la désactivation.

0
Zach Thompson