python 如何模块化 django settings.py？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2035733/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
how to modularize django settings.py?
提问by victor n.
When you install a new django application, you have to add/modify your settings.py module.
当您安装新的 django 应用程序时，您必须添加/修改您的 settings.py 模块。
For a project I'm trying to make that module a python subpackage and create a module for each application:
对于一个项目，我试图使该模块成为 python 子包并为每个应用程序创建一个模块：
settings\
__init__.py
base.py
admin.py
feincms.py
...
The problem I'm confronted with is how to merge settings.py attributes (INSTALLED_APPS for example is a tuple of values) that are getting values in the different submodules?
我面临的问题是如何合并在不同子模块中获取值的 settings.py 属性（例如 INSTALLED_APPS 是一组值）？
Thanks
谢谢
Ok, I asked the wrong question (got the right answer for it though). My question should have been, how to get attributes from all submodules and merge them? Django will import settings and expects everything to be there.
好吧，我问错了问题（虽然得到了正确的答案）。我的问题应该是，如何从所有子模块中获取属性并合并它们？Django 将导入设置并期望一切都在那里。
采纳答案by Carl Meyer
You might be interested in this solution; uses execfile() to load a series of settings files in order, where each file has full access to settings from previously-loaded files, to update, modify, etc.
您可能对此解决方案感兴趣；使用 execfile() 按顺序加载一系列设置文件，其中每个文件都可以完全访问先前加载的文件中的设置、更新、修改等。
回答by S.Lott
"When you install a new django application, you have to add/modify your settings.py module."
“当你安装一个新的 django 应用程序时，你必须添加/修改你的 settings.py 模块。”
I think this is fine as is.
我认为这很好。
I don't see any reason to change or modify this at all.
我根本看不到任何改变或修改它的理由。
What we do, however, is to "subclass" the core settings module.
然而，我们所做的是“子类化”核心设置模块。
Our developer-specific and installation-specific files have names like settings_devxy_linux2and settings_checkout_win32, etc.
我们特定于开发人员和特定于安装的文件的名称类似于settings_devxy_linux2和settings_checkout_win32等。
Each of these files starts with from settings import *to import the core settings and extend those core settings with overrides for a specific installation and platform.
这些文件中的每一个都首先from settings import *导入核心设置，并使用特定安装和平台的覆盖扩展这些核心设置。
It doesn't require any real work. It does, however, mean that we do most things with django-admin.pybecause our settings aren't called settings.
它不需要任何实际工作。然而，这确实意味着我们可以做大多数事情，django-admin.py因为我们的设置没有被调用settings。
回答by akaihola
I've used this work-around:
我已经使用了这个解决方法：
settings.py:
设置.py：
INSTALLED_APPS = ('whatever',)
import more_settings
more_settings.modify(globals())
more_settings.py:
more_settings.py:
def modify(settings):
settings['INSTALLED_APPS'] += ('another_app',)
回答by dArignac
I have the same structure of settings files and I do the following to import the settings of the submodules:
我有相同的设置文件结构，我执行以下操作来导入子模块的设置：
def load_settings_file(file):
file = open(os.path.join(INSTALL_DIR, '<projectname>', 'settings', file + '.py'))
content = file.read()
file.close()
return content
for submodule in ['base', 'admin', 'feincms']:
exec(load_settings_file(submodule))
回答by Karim Nassar
I created https://code.djangoproject.com/wiki/SplitSettings#SettingInheritancewithHierarchyas my preferred solution. Allows for inheritance from a common file in any deployment environment.
我创建了https://code.djangoproject.com/wiki/SplitSettings#SettingInheritancewithHierarchy作为我的首选解决方案。允许从任何部署环境中的公共文件继承。
回答by akaihola
If you prefer more magic than in my previous more_settings.modify()approach, try this:
如果你比我以前的more_settings.modify()方法更喜欢魔法，试试这个：
settings.py:
设置.py：
INSTALLED_APPS = ('whatever',)
import more_settings
more_settings.modify(globals())
more_settings.py:
more_settings.py:
def config(INSTALLED_APPS=(), **other_settings):
INSTALLED_APPS += ('another_app',)
del other_settings
return locals()
def modify(settings):
settings.update(config(**settings))
Pros: no need to refer to settings with dict notation
优点：无需使用 dict 表示法引用设置
Cons: must define modified settings as kwargs for config()
缺点：必须将修改后的设置定义为 kwargs config()
回答by Alex Martelli
Presumably the best way to "merge" varies, attributes by attributes. For example, given several tuples (from the INSTALLED_APPSof various submodules), you might simply concatenate them into a new tuple (for the INSTALLED_APPSattribute of the package as a whole), or, if possible duplications are a problem, so something smarter to remove the duplications (in this case you may not care about ordering, so simply tuple(set(tup1+tup2+tup3))might suffice).
据推测，“合并”的最佳方式因属性而异。例如，给定几个元组（来自INSTALLED_APPS各个子模块的），您可以简单地将它们连接成一个新的元组（对于INSTALLED_APPS整个包的属性），或者，如果可能，重复是一个问题，因此可以更聪明地删除重复（在这种情况下，您可能不关心排序，所以tuple(set(tup1+tup2+tup3))可能就足够了）。
For other cases ("merging" dictionaries, "merging" settings which are just scalars or strings, etc) you'll need different strategies (maybe successive .updatecalls for the dictionaries, pick just one according to some criteria for the scalars or strings, etc, etc) -- I just don't see a "one size fits all" approach working here.
对于其他情况（“合并”字典，“合并”只是标量或字符串的设置等），您将需要不同的策略（可能连续.update调用字典，根据标量或字符串的某些标准仅选择一个，等等等）——我只是没有看到“一刀切”的方法在这里工作。
回答by mo.
just put
就放
from base import *
from admin import *
...
in ur init.py that should work
在你的init.py 中应该可以工作
i used it for different sites
我将它用于不同的网站
base/settings.py # common settings: db, apps, ...
base/sites/website1/settings.py # site_id, custom middleware
base/sites/website2/settings.py # site_id, custom middleware
the website settings import the common settings with
网站设置导入常用设置
from base.settings import *
and define custom attribtues
并定义自定义属性
