在Django中同时使用多个配置文件的方法

我们仅仅处理一个单一的设置文件 settings.py文件由django-admin.py startproject命令生成。但是当你准备要进行配置的时候，你将发现你需要多个配置文件以使你的开发环境和产品环境相独立。 比如，你可能不想每次在本地机器上测试代码改变的时候将DEBUG从False 改为True。Django通过使用多个配置文件而使得这种情况很容易得到避免。

如果你想把你的配置文件按照产品设置和开发设置组织起来，你可以通过下面三种方法的其中一种达到这个目的。

  • 设置成两个全面的，彼此独立的配置文件
  • 设置一个基本的配置文件（比如，为了开发)和第二个（为了产品)配置文件，第二个配置文件仅仅从基本的那个配置文件导入配置，并对需要定义的进行复写.
  • 使用一个单独的配置文件，此配置文件包含一个Python的逻辑判断根据上下文环境改变设置。

我们将会在依次解释这几种方式

首先，最基本的方法是定义两个单独的配置文件。 如果你是跟随之前的例子做下来的，那么你已经有了一个settings.py了，现在你只需要将它复制一份并命名为settings_production.py（文件名可以按照你自己的喜好定义),在这个新文件中改变DEBUG等设置。

第二种方法比较类似，但是减少了许多冗余。 作为使用两个内容大部分相同的配置文件的替代方式，你可以使用一个文件为基本文件，另外一个文件从基本文件中导入相关设定。 例如

# settings.py

DEBUG = True
TEMPLATE_DEBUG = DEBUG

DATABASE_ENGINE = 'postgresql_psycopg2'
DATABASE_NAME = 'devdb'
DATABASE_USER = ''
DATABASE_PASSWORD = ''
DATABASE_PORT = ''

# ...

# settings_production.py

from settings import *

DEBUG = TEMPLATE_DEBUG = False
DATABASE_NAME = 'production'
DATABASE_USER = 'app'
DATABASE_PASSWORD = 'letmein'

此处，settings_production.py 从settings.py 导入所有的设定，仅仅只是重新定义了产品模式下需要特殊处理的设置。 在这个案例中，DEBUG 被设置为False，但是我们已经对产品模式设置了不同的数据库访问参数。 （后者将向你演示你可以重新定义 任何 设置，并不只是象 DEBUG 这样的基本设置。）

最终，最精简的达到两个配置环境设定的方案是使用一个配置文件，在此配置文件中根据不同的环境进行设置。 一个达到这个目的的方法是检查当前的主机名。 例如：

# settings.py

import socket

if socket.gethostname() == 'my-laptop':
  DEBUG = TEMPLATE_DEBUG = True
else:
  DEBUG = TEMPLATE_DEBUG = False

# ...

在这里，我们从python标准库导入了socket 模块，使用它来检查当前系统的主机名。 我们可以通过检查主机名来确认代码是否运行在产品服务器上。

一个关键是配置文件仅仅是包含python代码的文件。你可以从其他文件导入这些python代码，可以通过这些代码执行任意的逻辑判断等操作。 如果你打算按照这种方案走下去，请确定这些配置文件中的代码是足够安全（防弹)的。 如果这个配置文件抛出任何的异常，Django都有可能会发生很严重的崩溃。

重命名settings.py

随便将你的settings.py重命名为settings_dev.py或settings/dev.py或foobar.py，Django 并不在乎你的配置文件取什么名字，只要你告诉它你使用的哪个配置文件就可以了。

但是如果你真的重命名了由django-admin.py startproject 命令创建的settings.py文件，你会发现manage.py会给出一个错误信息说找不到配置文件。 那是由于它尝试从这个文件中导入一个叫做settings的模块，你可以通过修改manage.py 文件，将 import settings 语句改为导入你自己的模块，或者使用django-admin.py而不是使用manage.py,在后一种方式中你需要设置 DJANGO_SETTINGS_MODULE 环境变量为你的配置文件所在的python 路径.(比如'mysite.settings'）。
DJANGO_SETTINGS_MODULE

通过这种方式的代码改变后，本章的下一部分将集中在对具体环境(比如Apache)的发布所需要的指令上。 这些指令针对每一种环境都不同，但是有一件事情是相同的。 在每一种环境中，你都需要告诉Web服务器你的DJANGO_SETTINGS_MODULE是什么,这是你的Django应用程序的进入点。 DJANGO_SETTINGS_MODULE指向你的配置文件，在你的配置文件中指向你的ROOT_URLCONF,在ROOT_URLCONF中指向了你的视图以及其他的部分。

DJANGO_SETTINGS_MODULE是你的配置文件的python的路径 比如，假设mysite是在你的Python路径中，DJANGO_SETTINGS_MODULE对于我们正在进行的例子就是'mysite.settings'。

赞 (0)

相关推荐

  • 详解Python的Django框架中的Cookie相关处理

    浏览器的开发者在很早的时候就已经意识到, HTTP's 的无状态会对Web开发者带来很大的问题,于是(cookies)应运而生. cookies 是浏览器为 Web 服务器存储的一小段信息. 每次浏览器从某个服务器请求页面时,它向服务器回送之前收到的cookies 来看看它是怎么工作的. 当你打开浏览器并访问 google.com ,你的浏览器会给Google发送一个HTTP请求,起始部分就象这样: GET / HTTP/1.1 Host: google.com ... 当 Google响应时,

  • 在Python的Django框架的视图中使用Session的方法

    SessionMiddleware 激活后,每个传给视图(view)函数的第一个参数``HttpRequest`` 对象都有一个 session 属性,这是一个字典型的对象. 你可以象用普通字典一样来用它. 例如,在视图(view)中你可以这样用: # Set a session value: request.session["fav_color"] = "blue" # Get a session value -- this could be called in

  • 在Django的视图(View)外使用Session的方法

    从内部来看,每个session都只是一个普通的Django model(在 django.contrib.sessions.models 中定义).每个session都由一个随机的32字节哈希串来标识,并存储于cookie中. 因为它是一个标准的模型,所以你可以使用Django数据库API来存取session. >>> from django.contrib.sessions.models import Session >>> s = Session.objects.g

  • 在Django中同时使用多个配置文件的方法

    我们仅仅处理一个单一的设置文件 settings.py文件由django-admin.py startproject命令生成.但是当你准备要进行配置的时候,你将发现你需要多个配置文件以使你的开发环境和产品环境相独立. 比如,你可能不想每次在本地机器上测试代码改变的时候将DEBUG从False 改为True.Django通过使用多个配置文件而使得这种情况很容易得到避免. 如果你想把你的配置文件按照产品设置和开发设置组织起来,你可以通过下面三种方法的其中一种达到这个目的. 设置成两个全面的,彼此独立

  • 在django中,关于session的通用设置方法

    最近发现session的知识有点脱节了,默认设置愣是搞半天,看来忘了不少.今天把一些通用设置贴上来,以备随时回顾. 配置文件中设置默认操作(通用配置): SESSION_COOKIE_NAME ＝ "sessionid" # Session的cookie保存在浏览器上时的key,即:sessionid＝随机字符串(默认) SESSION_COOKIE_PATH ＝ "/" # Session的cookie保存的路径(默认) SESSION_COOKIE_DOMAIN

  • Django中url的反向查询的方法

    Django中url的反向查询的方法

    本文介绍了Django中url的反向查询的方法,分享给大家,具体如下: 明确几个概念: 1.application namespace : 正在部署的app的名称,一个app的多个实例应该具有相同的application namespace. 可以通过在URLconf模块(urls.py)中设置 app_name 属性(与urlpatterns属性同级)来指定application namesapce. (在django2.0版本中必须设置 app_name ) 2.instance names

  • django中模板的html自动转意方法

    一.需求来源: 如果用户在文本框中填了一段<script>alert(xxx);</script>代码,然后我们还保存在了数据库中,下次模板加载数据的时候,将这段代码显示在浏览器,将会弹出一个警告框.因此,这是XSS(跨域脚本)攻击的一种方式,我们肯定不能允许这种事件发生,因此django默认给我们启动了自动转意的功能.将这段代码转换成普通的文本进行展示. 二.如何关闭: 你肯定会问既然自动转意可以关闭XSS漏洞为什么需要关闭呢?原因很简单,如果你数据库中保存了一段可信任的HTML

  • 浅谈Django中view对数据库的调用方法

    question: Django中对数据库的调用非常的隐蔽,在各种复杂的模块互相拼接继承中很难发现获取数据库内容的部分 来,开始试图理解一下下 首先,数据库中的表对应的是model中的每一个类,类中的变量对应表的属性,通常属性名就是变量名.有一个比较特殊的东西就是ForeignKey,它代表了与其他表的关联约束键,即SQL中的约束键,通常和其他表中的主键primary key相关联. 理解了model是我们定义的数据表,接下来的事情就会越发的简单,我们都知道网页中的data信息是通过Django

  • 在Django中输出matplotlib生成的图片方法

    下面的代码片段是直接在Django中输出matplotlib生成的图片,网上很多种方法都是先生成图片再调用,感觉不是那么直接. 环境:Python2.7,Django1.83 该文件为views.py文件,函数映射按实际设置. from django.shortcuts import render from django.http import HttpResponse from matplotlib.figure import Figure from matplotlib.backends.b

  • Django中Aggregation聚合的基本使用方法

    Django 的 filter.exclude 等方法使得对数据库的查询很方便了.这在数据量较小的时候还不错,但如果数据量很大,或者查询条件比较复杂,那么查询效率就会很低. 提高数据库查询效率可以通过原生 SQL 语句来实现,但是它的缺点就是需要开发者熟练掌握 SQL.倘若查询条件是动态变化的,则编写 SQL 会更加困难. 对于以便捷著称的 Django,怎么能忍受这样的事.于是就有了 Aggregation聚合 . 聚合最好的例子就是官网给的案例了: # models.py from djan

  • django中使用原生sql语句的方法步骤

    raw # row方法:(掺杂着原生sql和orm来执行的操作) res = CookBook.objects.raw('select id as nid from epos_cookbook where id>%s', params=[1, ]) print(res.columns) # ['nid'] print(type(res)) # <class 'django.db.models.query.RawQuerySet'> # 在select里面查询到的数据orm里面的要一一对应

  • Django中信号signals的简单使用方法

    正文 在平时的开发过程中,我们会遇到一些特殊的应用场景,如果你想要在执行某种操作之前或者之后你能够得到通知,并对其进行一些你想要的操作时,你就可以用Django中的信号(signals).Django 提供一个"信号分发器",允许解耦的应用在框架的其它地方发生操作时会被通知到,也就是说在特定事件发生时,可以发送一个信号去通知所有注册了这个信号的回调,在回调里进行想要的操作处理. 一.Django内置信号 Django内置了对数据表,migrate命令,url请求相关(request/r

  • django中静态文件配置static的方法

    环境 centos7 django 1.11 nginx 白话 我们可以使用Template 设置我们的网页,同时,一个完美的网页需要css,js,image 等静态文件的支持. django中配置方式貌似有不少总,因为很多相关的博客写的方式并不一致,当然这可能是django 的版本不同导致的. 当我们在一个项目下创建一个app后,我们就需要为该app下创建一个static 文件夹来存放相关静态资源. 但创建了多个app后,就需要在多个app下创建static. 这样引入了一个问题,因为,我们的

随机推荐