configurando una variable de entorno en virtualenv

Tengo un proyecto Heroku que usa variables de entorno para obtener su configuración, pero primero uso virtualenv para probar mi aplicación localmente.

¿Hay alguna manera de establecer las variables de entorno definidas en la máquina remota dentro de virtualenv?

Actualizar

A partir del 17 de mayo de 2017, el README de autoenv afirma que direnv es probablemente la mejor opción e implica que autoenv ya no se mantiene.

Vieja respuesta

Escribí autoenv para hacer exactamente esto:

https://github.com/kennethreitz/autoenv

En caso de que estés usando virtualenvwrapper (te recomiendo hacerlo), puedes definir diferentes ganchos (preactivate, postactivate, preactivate, postdeactivate) usando los scripts con los mismos nombres en $VIRTUAL_ENV/bin/ . Necesitas el gancho postactivado.

 $ 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 desea mantener esta configuración en el directorio de su proyecto, simplemente cree un enlace simbólico desde el directorio de su proyecto a $VIRTUAL_ENV/bin/postactivate .

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

Incluso podría automatizar la creación de los enlaces simbólicos cada vez que use mkvirtualenv .

Limpiando en desactivar

Recuerda que esto no va a limpiar después de sí mismo. Cuando desactivas el virtualenv, la variable de entorno persistirá. Para limpiar simétricamente, puede agregar a $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 

Recuerde que si usa esto para las variables de entorno que ya podrían estar configuradas en su entorno, el desarmado hará que se desestabilicen por completo al dejar virtualenv. Por lo tanto, si es probable, puede registrar el valor anterior en algún lugar temporal y luego leerlo nuevamente al desactivar.

Preparar:

 $ 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 

Prueba:

 $ echo $SOME_VAR banana $ workon myenv $ echo $SOME_VAR apple $ deactivate $ echo $SOME_VAR banana 

Tu podrías intentar:

 export ENVVAR=value 

en virtualenv_root / bin / activar. Básicamente, el script de activación es lo que se ejecuta cuando empiezas a usar virtualenv para que puedas poner toda tu personalización allí.

Usando solo virtualenv (sin virtualenvwrapper ), configurar las variables de entorno es fácil a través de la secuencia de comandos activate usted solicita para activar virtualenv.

Correr:

 nano YOUR_ENV/bin/activate 

Agregue las variables de entorno al final del archivo de esta manera:

 export KEY=VALUE 

También puede establecer un gancho similar para desarmar la variable de entorno como lo sugiere Danilo Bargen en su excelente respuesta anterior, si la necesita.

Si bien hay muchas respuestas agradables aquí, no vi una solución publicada que incluya la desactivación de variables de entorno al desactivar y no requiera bibliotecas adicionales más allá de virtualenv , así que aquí está mi solución que solo implica editar / bin / activar, usar Las variables MY_SERVER_NAME y MY_DATABASE_URL como ejemplos:

Debería haber una definición para desactivar en el script de activación, y desea desactivar sus variables al final de la misma:

 deactivate () { ... # Unset My Server's variables unset MY_SERVER_NAME unset MY_DATABASE_URL } 

Luego, al final del script de activación, establezca las variables:

 # Set My Server's variables export MY_SERVER_NAME="" export MY_DATABASE_URL="" 

De esta manera, no tiene que instalar nada más para que funcione, y no termina con las variables que quedan cuando deactivate el virtualenv.

Localmente dentro de un virtualenv hay dos métodos que podrías usar para probar esto. La primera es una herramienta que se instala a través del cinturón de herramientas de Heroku (https://toolbelt.heroku.com/). La herramienta es capataz. Exportará todas las variables de entorno que están almacenadas en un archivo .env localmente y luego ejecutará los procesos de la aplicación dentro de su archivo Procfile.

La segunda forma, si está buscando un enfoque más ligero, es tener un archivo .env localmente y luego ejecutar:

 export $(cat .env) 

Instala autoenv ya sea por

 $ pip install autoenv 

(o)

 $ brew install autoenv 

Y luego crea el archivo .env en tu carpeta de proyecto virtualenv

 $ echo "source bin/activate" > .env 

Ahora todo funciona bien.

Otra forma de hacerlo que está diseñada para django, pero debería funcionar en la mayoría de las configuraciones, es usar django-dotenv.

Si ya está utilizando Heroku, considere ejecutar su servidor a través de Foreman . Admite un archivo .env que es simplemente una lista de líneas con KEY=VAL que se exportará a su aplicación antes de que se ejecute.

Otro enfoque es bifurcar un shell bash con un venv corriendo dentro. Ejecuta un ejecutable que contiene:

 # my_env.sh export MY_VENV=true bash 

En ~ / .bashrc poner:

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

Al salir del shell bifurcado se restaura el entorno original, y no tiene que ejecutar la desactivación.