Eu tenho um projeto Heroku que usa variáveis ​​de ambiente para obter sua configuração, mas eu uso o virtualenv para testar meu aplicativo localmente primeiro.

Existe uma maneira de definir as variáveis ​​de ambiente definidas na máquina remota dentro do virtualenv?

Atualizar

A partir de 17 de maio de 2017, o README da autoenv indica que o direnv é provavelmente a melhor opção e implica que o autoenv não é mais mantido.

Resposta antiga

Eu escrevi autoenv para fazer exatamente isso:

https://github.com/kennethreitz/autoenv

Caso esteja usando o virtualenvwrapper (eu recomendo isso), você pode definir diferentes ganchos (pré-ativar, pós-ativar, pré-ativar, pós-desativar) usando os scripts com os mesmos nomes em $VIRTUAL_ENV/bin/. Você precisa do gancho pós-ativo.

$ 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 você deseja manter essa configuração no diretório do projeto, basta criar um link simbólico do diretório do projeto para $VIRTUAL_ENV/bin/postactivate.

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

Você pode até automatizar a criação dos links simbólicos toda vez que usar mkvirtualenv .

Limpando e desativando

Lembre-se de que isso não será limpo depois de si. Quando você desativa o virtualenv, a variável de ambiente persiste. Para limpar simetricamente, você pode adicionar 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

Lembre-se de que, se estiver usando isso para variáveis ​​de ambiente que já podem estar configuradas em seu ambiente, a desativação resultará na desativação completa da saída da virtualenv. Portanto, se é provável que você possa registrar o valor anterior em algum lugar temporário, leia-o novamente em desativar.

Configuração:

$ 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

Teste:

$ echo $SOME_VAR
banana

$ workon myenv

$ echo $SOME_VAR
apple

$ deactivate

$ echo $SOME_VAR
banana

Você poderia tentar:

export ENVVAR=value

em virtualenv_root / bin / activar. Basicamente, o script de ativação é o que é executado quando você começa a usar o virtualenv, para que possa colocar toda a sua personalização lá.

Usando apenas virtualenv (sem virtualenvwrapper ), é fácil definir variáveis ​​de ambiente através do activatescript que você utiliza para ativar o virtualenv.

Corre:

nano YOUR_ENV/bin/activate

Adicione as variáveis ​​de ambiente ao final do arquivo, assim:

export KEY=VALUE

Você também pode definir um gancho semelhante para desabilitar a variável de ambiente, conforme sugerido por Danilo Bargen em sua excelente resposta acima, se necessário.

Embora haja muitas respostas legais aqui, não vi uma solução publicada que inclua a desativação de variáveis ​​de ambiente na desativação e não exija bibliotecas adicionais além virtualenv, então aqui está minha solução que envolve apenas editar / bin / ativar, usando o variáveis MY_SERVER_NAMEe MY_DATABASE_URLcomo exemplos:

Deve haver uma definição para desativar no script de ativação, e você deseja desmarcar suas variáveis ​​no final dele:

deactivate () {
    ...

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

Em seguida, no final do script de ativação, defina as variáveis:

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

Dessa forma, você não precisa instalar mais nada para fazê-lo funcionar e não acaba com as variáveis ​​que sobraram quando deactivateo virtualenv.

Localmente em um virtualenv, existem dois métodos que você pode usar para testar isso. A primeira é uma ferramenta instalada através do cinto de ferramentas Heroku (https://toolbelt.heroku.com/). A ferramenta é capataz. Ele exportará todas as variáveis ​​de ambiente armazenadas em um arquivo .env localmente e, em seguida, executará os processos do aplicativo no seu Procfile.

A segunda maneira, se você estiver procurando uma abordagem mais leve, é ter um arquivo .env localmente e executar:

export $(cat .env)

Instale o autoenv por

$ pip install autoenv

(ou)

$ brew install autoenv

E, em seguida, crie um .envarquivo na pasta do projeto virtualenv

$ echo "source bin/activate" > .env

Agora tudo funciona bem.

Se você já usa o Heroku, considere executar o servidor via Foreman . Ele suporta um .envarquivo que é simplesmente uma lista de linhas KEY=VALque serão exportadas para o seu aplicativo antes da execução.

Outra maneira de fazer isso, projetada para o django, mas deve funcionar na maioria das configurações, é usar o django-dotenv.

• Original - https://github.com/jacobian/django-dotenv
• Garfo mais completo - https://github.com/tedtieken/django-dotenv-rw (escrevi para poder definir minhas configurações de .env remotas no webfaction na minha linha de comando local, o heroku me mimava)

Para ativar o virtualenv no envdiretório e exportar variáveis ​​de ambiente armazenadas em .envuso:

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