Dúvida em relação ao arquivo .ini ou .env

[hlrossato]

Fala Henrique, blz cara?! Cara, estou com uma dúvida em relação ao python-decouple e queria ver se você poderia responder. Minha dúvida é a seguinte: Usando o decouple vou ter minhas variáveis setadas no .ini ou .env e o decouple vai acessar esse arquivo e pegar esses valores. Até ai tudo bem, mas esse arquivo não é comitado, certo?! Nesse caso, ele ficaria na minha máquina. Como faz quando um novo dev vai desenvolver? E se eu perder esse arquivo (formatar a máquina, der algum pau sei lá). Pode parecer idiota a pergunta mas é uma pergunta que não consegui sanar. Desde já agradeço. Abraço

[tporto]

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.

[hlrossato]

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.

[tporto]

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

[hlrossato]

@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.

[fgmacedo]

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,

[hlrossato]

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

[henriquebastos]

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.