Dúvida em relação ao arquivo .ini ou .env about python-decouple HOT 7 CLOSED

Onde trabalho usamos da seguinte forma: criamos um outro arquivo chamado .env.example e nele vai todas as chaves sem valor e vai no commit. Se um outro desenvolvedor precisa trabalhar no projeto ele cria um arquivo .env se baseando no .env.example e preenche as chaves. Caso seja necessário uma nova chave adicionamos no .env.example que é para todos saberem que há chave nova.

from python-decouple.

Interessante @tporto. Mesmo conceito que eu usava/uso para gerenciar o meu local_settings.py. Tem sempre um template no projeto para que os novos devs iniciem a partir dele. Mas minha dúvida ainda permanece, pois e no caso da SECRET_KEY? As outras informações como db, email, tudo bem mas a SK é por projeto.

from python-decouple.

A secret_key usamos a que o django gera no projeto. Geramos uma nova apenas no deploy.

from python-decouple.

@tporto Então você gera uma nova secret_key pro deploy e todos os devs usam a secret_key que o django gerou e está no seu .env_template, certo?! Interessante. Parece ser uma boa alternativa.

from python-decouple.

Apenas apresentando como alternativa, aqui temos adotado uma abordagem ligeiramente diferente: Temos apenas um settings.py (sem settings_local.py), e as configurações onde é possível estipular um padrão razoável são todas orientadas ao ambiente de produção, como por exemplo:

DEBUG = config("DEBUG", default=False, cast=bool)

As configurações sensíveis, como SECRET_KEY, simplesmente não tem valor padrão:

SECRET_KEY = config('SECRET_KEY')

Desde modo, ao subir o projeto em uma máquina nova, o desenvolvedor é obrigado a estipular um valor para o seu ambiente.

Para integração com serviços "plugáveis", que podem ser desabilitados em um ambiente local sem que a aplicação seja comprometida, deixamos um valor padrão falsy e verificamos se o serviço deve ser ativado com base no valor da configuração. Por exemplo, uma aplicação pode habilitar notificações PUSH no celular, se o Token do IONIC existe:

IONIC_TOKEN = config('IONIC_TOKEN', default=None)

E no código:

@shared_task(name='notification.notify_mobile')
def notify_mobile(notification_id, instance=None, session=None):
    if not settings.IONIC_TOKEN:
        return  # Notificação está desligada
    ...  

Aqui fazemos assim. Também acho bacana a abordagem de ter um .env.example, só é necessário um cuidado adicional para manter o exemplo atualizado. Aqui nossa fonte única da verdade é o settings.py. Se tem um config('CHAVE_QUALQUER' lá significa que a configuração pode ser sobrescrita. Os devs se acostumam a olhar o código e se familiarizar com as variáveis mais comuns.

Abs,

from python-decouple.

Interessante a ideia também @fgmacedo . Obrigado pela dica.

from python-decouple.

Nos meus projetos eu tenho um diretório contrib com um shell script que monta o meu .env ou settings.ini. Uso isso apenas quando um novo developer pega o projeto. No mais, o processo de deploy sempre usa variáveis de ambiente.

O propósito do python-decoupl é você nunca precisar de mais de um settings.py, variando apenas as variáveis de ambiente.

Boa thread essa! Se acharem que dá pra pegar os aprendizados que vcs discutiram aqui e melhorar o README, pull request são bem-vindos.

from python-decouple.