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

Existe-t-il un moyen de définir les variables d'environnement définies sur la machine distante dans virtualenv?

Mettre à jour

Depuis le 17 mai 2017, le fichier README d'autoenv indique que direnv est probablement la meilleure option et implique qu'autoenv n'est plus maintenu.

Ancienne réponse

J'ai écrit autoenv pour faire exactement ceci:

https://github.com/kennethreitz/autoenv

Si vous utilisez virtualenvwrapper (je vous recommande vivement de le faire), vous pouvez définir différents hooks (préactiver, postactiver, prédéactiver, postdésactiver) en utilisant les scripts avec les mêmes noms dans $VIRTUAL_ENV/bin/. Vous avez besoin du crochet de post-activation.

$ 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 lors de la désactivation

N'oubliez pas que cela ne nettoiera pas après lui-même. Lorsque vous désactivez virtualenv, la variable d'environnement persiste. Pour nettoyer symétriquement, 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 l'utilisez pour des variables d'environnement qui peuvent déjà être définies dans votre environnement, la désactivation entraînera leur désactivation complète lorsque vous quittez virtualenv. Donc, si cela est probable, vous pouvez enregistrer la valeur précédente quelque part temporairement, puis la relire lors de 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

Tu pourrais essayer:

export ENVVAR=value

dans virtualenv_root / bin / activate. Fondamentalement, le script d'activation est ce qui est exécuté lorsque vous commencez à utiliser virtualenv afin que vous puissiez y mettre toute votre personnalisation.

En utilisant uniquement virtualenv (sans virtualenvwrapper ), la configuration des variables d'environnement est facile grâce au activatescript que vous sourcez afin d'activer 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 hook similaire pour annuler la variable d'environnement comme suggéré par Danilo Bargen dans sa grande réponse ci-dessus si vous en avez besoin.

Bien qu'il y ait beaucoup de bonnes réponses ici, je n'ai pas vu de solution publiée qui inclut à la fois la désactivation des variables d'environnement lors de la désactivation et ne nécessite pas de bibliothèques supplémentaires au virtualenv- delà , voici donc ma solution qui consiste simplement à modifier / bin / activate, en utilisant le variables MY_SERVER_NAMEet MY_DATABASE_URLcomme exemples:

Il devrait y avoir une définition de la désactivation dans le script d'activation, et vous souhaitez annuler la définition de vos variables à la fin:

deactivate () {
    ...

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

Puis à 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 retrouvez pas avec les variables restantes lorsque vous deactivateutilisez virtualenv.

Localement, dans un virtualenv, vous pouvez utiliser deux méthodes pour tester cela. Le premier est un outil qui s'installe via la ceinture à outils Heroku (https://toolbelt.heroku.com/). L'outil est contremaître. Il exportera toutes vos variables d'environnement qui sont stockées dans un fichier .env localement, puis exécutera les processus d'application dans votre Procfile.

La deuxième façon si vous recherchez une approche plus légère est d'avoir un fichier .env localement, puis exécutez:

export $(cat .env)

Installez autoenv soit en

$ pip install autoenv

(ou)

$ brew install autoenv

Et puis créez le .envfichier dans votre dossier de projet virtualenv

$ echo "source bin/activate" > .env

Maintenant, tout fonctionne bien.

Si vous utilisez déjà Heroku, envisagez d'exécuter votre serveur via Foreman . Il prend en charge un .envfichier qui est simplement une liste de lignes KEY=VALqui seront exportées vers votre application avant son exécution.

Une autre façon de le faire, conçue pour django, mais qui devrait fonctionner dans la plupart des paramètres, est d'utiliser django-dotenv.

• Original - https://github.com/jacobian/django-dotenv
• Fork plus complet - https://github.com/tedtieken/django-dotenv-rw (j'ai écrit ceci pour pouvoir définir mes paramètres .env à distance sur webfaction à partir de ma ligne de commande locale, heroku m'a gâté)

Pour activer virtualenv dans le envrépertoire et exporter les variables d'environnement stockées en cours d' .envutilisation:

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