bootstrap - template python




Como você configura o Django para desenvolvimento e implementação simples? (10)

A maneira mais simplista que encontrei foi:

1) use o settings.py padrão para desenvolvimento local e 2) crie um production-settings.py começando com:

import os
from settings import *

Em seguida, basta substituir as configurações que diferem na produção:

DEBUG = False
TEMPLATE_DEBUG = DEBUG


DATABASES = {
    'default': {
           ....
    }
}

Eu costumo usar o SQLite ao fazer o desenvolvimento do Django , mas em um servidor ativo algo mais robusto é necessário ( MySQL / PostgreSQL , por exemplo). Invariavelmente, existem outras mudanças a serem feitas nas configurações do Django: diferentes locais / intensidades de registro, caminhos de mídia, etc.

Como você gerencia todas essas mudanças para tornar a implantação um processo simples e automatizado?


Além dos vários arquivos de configurações mencionados por Jim, também tenho a tendência de colocar duas configurações no meu arquivo settings.py no topo BASE_DIR e BASE_URL definido para o caminho do código e o URL para a base do site, todas as outras configurações são modificados para se anexar a eles.

BASE_DIR = "/home/sean/myapp/" por exemplo, MEDIA_ROOT = "%smedia/" % BASEDIR

Então, ao mover o projeto, eu só tenho que editar essas configurações e não pesquisar o arquivo inteiro.

Eu também recomendaria ver o Fabric e o Capistrano (ferramenta Ruby, mas ele pode ser usado para implementar aplicativos Django) que facilitam a automação da implementação remota.


Bem, eu uso essa configuração:

No final do settings.py:

#settings.py
try:
    from locale_settings import *
except ImportError:
    pass

E em locale_settings.py:

#locale_settings.py
class Settings(object):

    def __init__(self):
        import settings
        self.settings = settings

    def __getattr__(self, name):
        return getattr(self.settings, name)

settings = Settings()

INSTALLED_APPS = settings.INSTALLED_APPS + (
    'gunicorn',)

# Delete duplicate settings maybe not needed, but I prefer to do it.
del settings
del Settings

Esta é uma postagem mais antiga, mas acho que, se adicionar essa library útil, simplificará as coisas.

Use django-configuration

Começo rápido

pip install django-configurations

Em seguida, subclasse as configurações incluídas. Classe de configuração no settings.py do seu projeto ou qualquer outro módulo que você esteja usando para armazenar as constantes de configurações, por exemplo:

# mysite/settings.py

from configurations import Configuration

class Dev(Configuration):
    DEBUG = True

Configure a variável de ambiente DJANGO_CONFIGURATION para o nome da classe que você acabou de criar, por exemplo, em ~/.bashrc :

export DJANGO_CONFIGURATION=Dev

e a variável de ambiente DJANGO_SETTINGS_MODULE para o caminho de importação do módulo, como por exemplo, no bash:

export DJANGO_SETTINGS_MODULE=mysite.settings

Alternativamente, forneça a opção --configuration ao usar os comandos de gerenciamento do Django ao longo das linhas da opção default --settings do Django, por exemplo:

python manage.py runserver --settings=mysite.settings --configuration=Dev

Para permitir que o Django use sua configuração, você agora tem que modificar seu script manage.py ou wsgi.py para usar as versões do django- settings das funções iniciais apropriadas, por exemplo, um manage.py típico usando configurações do django seria assim:

#!/usr/bin/env python

import os
import sys

if __name__ == "__main__":
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
    os.environ.setdefault('DJANGO_CONFIGURATION', 'Dev')

    from configurations.management import execute_from_command_line

    execute_from_command_line(sys.argv)

Observe na linha 10 que não usamos a ferramenta comum django.core.management.execute_from_command_line mas em vez disso configurations.management.execute_from_command_line .

O mesmo se aplica ao seu arquivo wsgi.py , por exemplo:

import os

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
os.environ.setdefault('DJANGO_CONFIGURATION', 'Dev')

from configurations.wsgi import get_wsgi_application

application = get_wsgi_application()

Aqui nós não usamos a função padrão django.core.wsgi.get_wsgi_application mas em vez disso configurations.wsgi.get_wsgi_application .

É isso aí! Agora você pode usar seu projeto com o manage.py e seu servidor WSGI habilitado.


Eu tenho dois arquivos. settings_base.py que contém settings_base.py comuns / padrão e que é verificado no controle de origem. Cada implantação possui um settings.py separado, que é executado a from settings_base import * no início e, em seguida, sobrescreve conforme necessário.


Eu tenho meu arquivo settings.py em um diretório externo. Dessa forma, ele não é verificado no controle de origem ou sobrescrito por uma implantação. Eu coloquei isso no arquivo settings.py no meu projeto Django, junto com qualquer configuração padrão:

import sys
import os.path

def _load_settings(path):    
    print "Loading configuration from %s" % (path)
    if os.path.exists(path):
    settings = {}
    # execfile can't modify globals directly, so we will load them manually
    execfile(path, globals(), settings)
    for setting in settings:
        globals()[setting] = settings[setting]

_load_settings("/usr/local/conf/local_settings.py")

Nota: Isso é muito perigoso se você não pode confiar em local_settings.py.


Na verdade, você provavelmente deveria considerar ter as mesmas (ou quase as mesmas) configurações para o seu ambiente de desenvolvimento e produção. Caso contrário, situações como "Ei, funciona na minha máquina" acontecerão de tempos em tempos.

Portanto, para automatizar sua implantação e eliminar esses problemas do WOMM, basta usar o Docker .


No final do settings.py eu tenho o seguinte:

try:
    from settings_local import *
except ImportError:
    pass

Desta forma, se eu quiser substituir as configurações padrão, basta colocar settings_local.py ao lado de settings.py.


Tantas respostas complicadas!

Todo arquivo settings.py vem com:

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

Eu uso esse diretório para definir a variável DEBUG assim (substitua pelo diretório onde seu código de desenvolvimento é):

DEBUG=False
if(BASE_DIR=="/path/to/my/dev/dir"):
    DEBUG = True

Então, toda vez que o arquivo settings.py for movido, o DEBUG será False e seu ambiente de produção.

Toda vez que você precisar de configurações diferentes daquelas em seu ambiente de desenvolvimento, use:

if(DEBUG):
    #Debug setting
else:
    #Release setting

Update: django-configurations foram lançadas, o que provavelmente é uma opção melhor para a maioria das pessoas do que fazê-lo manualmente.

Se você preferir fazer as coisas manualmente, minha resposta anterior ainda se aplica:

Eu tenho vários arquivos de configurações.

  • settings_local.py - configuração específica do host, como nome do banco de dados, caminhos de arquivo, etc.
  • settings_development.py - configuração usada para desenvolvimento, por exemplo, DEBUG = True .
  • settings_production.py - configuração usada para produção, por exemplo, SERVER_EMAIL .

Eu amarro tudo isso junto com um arquivo settings.py que primeiro importa settings_local.py e depois um dos outros dois. Ele decide quais carregar por duas configurações em settings_local.py - DEVELOPMENT_HOSTS e PRODUCTION_HOSTS . settings.py chama o platform.node() para encontrar o nome do host da máquina em que está sendo executado e, em seguida, procura pelo nome do host nas listas e carrega o segundo arquivo de configurações, dependendo da lista na qual ele encontra o nome do host.

Dessa forma, a única coisa com a qual você realmente precisa se preocupar é manter o arquivo settings_local.py atualizado com a configuração específica do host e tudo o mais é tratado automaticamente.

Confira um exemplo here .





django