Ho un progetto Heroku che utilizza variabili di ambiente per ottenere la sua configurazione, ma uso virtualenv per testare prima la mia app localmente.

Esiste un modo per impostare le variabili di ambiente definite sul computer remoto all'interno di virtualenv?

Aggiornare

A partire dal 17 maggio 2017 il README di autoenv afferma che direnv è probabilmente l'opzione migliore e implica che autoenv non è più mantenuto.

Vecchia risposta

Ho scritto autoenv per fare esattamente questo:

https://github.com/kennethreitz/autoenv

Nel caso in cui utilizzi virtualenvwrapper (consiglio vivamente di farlo), puoi definire diversi hook (preactivate, postactivate, preeactivate, postdeactivate) usando gli script con gli stessi nomi in $VIRTUAL_ENV/bin/. È necessario il gancio postattivo.

$ 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

Se si desidera mantenere questa configurazione nella directory del progetto, è sufficiente creare un collegamento simbolico dalla directory del progetto a $VIRTUAL_ENV/bin/postactivate.

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

Puoi persino automatizzare la creazione dei symlink ogni volta che usi mkvirtualenv .

Pulizia in disattivazione

Ricorda che questo non pulirà dopo se stesso. Quando si disattiva virtualenv, la variabile di ambiente persiste. Per pulire simmetricamente puoi aggiungere 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

Ricorda che se lo usi per le variabili di ambiente che potrebbero essere già state impostate nel tuo ambiente, unset determinerà la loro totale disattivazione all'uscita da virtualenv. Quindi, se è del tutto probabile, è possibile registrare il valore precedente da qualche parte temporaneamente, quindi rileggerlo su Disattiva.

Impostare:

$ 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

Puoi provare:

export ENVVAR=value

in virtualenv_root / bin / activ. Fondamentalmente lo script di attivazione è ciò che viene eseguito quando inizi a utilizzare virtualenv in modo da poter inserire tutta la tua personalizzazione.

Usando solo virtualenv (senza virtualenvwrapper ), impostare le variabili di ambiente è facile attraverso lo activatescript che si sta procurando per attivare virtualenv.

Correre:

nano YOUR_ENV/bin/activate

Aggiungi le variabili di ambiente alla fine del file in questo modo:

export KEY=VALUE

Puoi anche impostare un hook simile per disinserire la variabile d'ambiente come suggerito da Danilo Bargen nella sua ottima risposta sopra, se necessario.

Mentre ci sono molte belle risposte qui, non ho visto una soluzione pubblicata che includa entrambe le variabili di ambiente disabilitanti su disattivato e non richieda ulteriori librerie oltre virtualenv, quindi ecco la mia soluzione che prevede solo la modifica / bin / activ, usando il variabili MY_SERVER_NAMEe MY_DATABASE_URLcome esempi:

Dovrebbe esserci una definizione per disattivare nello script activ e alla fine di essa vuoi disinserire le variabili:

deactivate () {
    ...

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

Quindi alla fine dello script activ, imposta le variabili:

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

In questo modo non è necessario installare nient'altro per farlo funzionare e non si finisce con le variabili che vengono lasciate quando si deactivatevirtualenv.

A livello locale all'interno di virtualenv ci sono due metodi che è possibile utilizzare per testarlo. Il primo è uno strumento che viene installato tramite la cintura degli strumenti Heroku (https://toolbelt.heroku.com/). Lo strumento è caposquadra. Esporterà tutte le variabili di ambiente archiviate in un file .env localmente e quindi eseguirà i processi delle app all'interno di Procfile.

Il secondo modo se stai cercando un approccio più leggero è avere un file .env localmente quindi eseguire:

export $(cat .env)

Installa autoenv o di

$ pip install autoenv

(o)

$ brew install autoenv

E quindi creare il .envfile nella cartella del progetto virtualenv

$ echo "source bin/activate" > .env

Ora tutto funziona bene.

Se stai già utilizzando Heroku, considera di eseguire il tuo server tramite Foreman . Supporta un .envfile che è semplicemente un elenco di righe KEY=VALche verranno esportate nella tua app prima che venga eseguita.

Un altro modo per farlo progettato per django, ma dovrebbe funzionare nella maggior parte delle impostazioni, è usare django-dotenv.

• Originale - https://github.com/jacobian/django-dotenv
• Fork più completo- https://github.com/tedtieken/django-dotenv-rw (ho scritto questo per essere in grado di configurare le mie impostazioni .env remote su webfaction dalla mia riga di comando locale, heroku mi ha rovinato)

Per attivare virtualenv nella envdirectory ed esportare le variabili envinroment memorizzate in .envuso:

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