13518219792
根据您的个性需求进行定制 先人一步 抢占小程序红利时代
让我们来讨论一下如何配置Python应用程序，特别是那些可能存在于多个环境中的应用程序——开发环境、模拟环境、生产环境等等……
应用程序中使用的工具和框架并不是特别重要，因为我将在下面概述的方法是基于普通Python的。这种方法的出现是由于使用Django设置会令人懊恼，此外，这种方法还是我将要处理的任何Python应用程序的选择。
我最喜欢的Python特性之一是，构成你应用程序的文件和目录与你在代码中导入和使用它们的方式是一一对应的。
例如，给定这个import语句:
我们可以推断出以下目录结构:
许多语言和框架都依赖于这个新概念，包括Clojure和ES6。
在我们的示例中，Python将utils目录视为一个Package。当你在一个目录中放置一个空的__init__.py时，该目录就变成了一个包。
作为一名Python黑客，你可能会遇到这样一个常见的场景，其中有一个utils.py文件最终会变得太大，因此你将它拆分成一个包含许多较小文件的utils//目录。
当遇到这种情况时，我们可以做以下事情:
所以现在我们已经看到了一个Python包是由一个目录中是否存在一个__init__.py文件决定的…但是如果这个文件不是空的呢?
由于它只是一个普通的旧Python文件，你可以把任何你想要的东西放在其中，该文件会在第一次导入包时被执行。
>>>旁注
通常我们不赞成将代码放在__init__.py中，因为它会在导入时带来意想不到的副作用。
你可以自己测试一下。创建一个名为foo的目录，并给它一个空的__init__.py文件。
从相同目录中的Python REPL运行以下代码:
这里没有输出是很好的，这意味着语句成功运行。
现在让我们编辑我们的__init__.py文件以包含以下代码:
sys.exit()通常用于使一个进程以特定的状态退出。
在一个新的REPL中重新运行相同的实验，你将观察到你的Python shell在导入之后会立即退出。在更大的应用程序中，效果会更明显:整个应用程序将退出。
这样，我们了解了基本原理，并了解了如何恶意使用此功能。
也许我们可以用它来做好事?
你的应用程序可能存在于多个环境中。你的本地开发环境可能是第一个，并且你可能有一个位于Jenkins或另一个CI平台上的测试环境。你的代码被部署到一个生产或活动环境中。一些系统可能有一个模拟环境，在实际运行之前使用。
即使你只认为自己是一个业余爱好者，在本地开发代码并将其部署到一个vps或类Heroku平台上也意味着你要处理多个环境。
我在构建应用程序时遵循的一个规则是，我应该能够将代码库部署到任何环境中(无需修改)，前提是我们有办法告诉系统它在哪里运行。
与此相比，为每个部署目标构建多个部件，需要额外的时间和复杂性来构建和保持。这些部件通常被设计为在单一目标环境中运行，因此在本地或测试模式中运行它们通常是困难的或不可能的。
著名的十二因素方法论也认同这一观点，并且认为所有配置都应该作为环境变量存在。我在一定程度上同意这一点，但有时有一种趋势，就是把所有东西都变成一个环境变量，很快就会变得难以支持。
如果你的系统的每个旋钮和刻度盘都是一个环境变量，那么你将发现，你最终会将各种变量的组合存储在某个地方，以便运行或调试。在这里看到问题了吗?我们将配置从一个区域(代码，通常保存在版本控制中)移出，并将它们移到更容易出现错误和人为错误的区域。
我用来划定界限的一般准则:
为了让应用程序在不同环境之间改变其行为，我们需要一种方法来告诉它，它正在哪里运行。依赖于环境变量(看到模式了吗?)，我倾向于使用ENV(或变体)来实现此目的。
>>>旁注
在改变底层框架或工具的运行时行为的标志与特定应用程序的操作模式的标志之间划一条线是很重要的。例如，有时一个简单的DEBUG=True/False并不够好。
我最近为一个客户完成一个带有以下约定的项目:
注意:考虑不设置这个变量的后果是很重要的。这会是灾难性的吗?例如，应用程序能否在生产集群内部以DEV模式启动，并最终向公众显示回溯信息?对于某些应用程序，默认设置应该是production。这里没有正确或错误的答案，但它需要被考虑。
从开发者的角度来看，我们想要像这样访问我们的配置:
上面的导入行不包含任何能提示我们所处环境的内容。我们在任何地方都没有看到development或production这样的词。相反，我们只导入了我们需要的，并允许配置系统来决定它来自何处。
我们利用文件系统和语言本身来提供一个用于读取配置的API。
在幕后，这是config目录在磁盘上的样子:
让我们来看看common.py:
这是一个人为的例子，所以请不要太深入地了解细节。需要注意的是，这是一个相当静态的配置，不会经常改变。
现在让我们来看看environment/development.py：
回到我们的config/__init__.py文件，我们可以在这里实现什么来实现它呢?其实很简单:
我们正在利用import-time evaluation来动态地从相应的子环境中获取必要的配置。让我们一步一步来:
1. 首先，我们导入importlib模块(文档)，它为我们提供了一些用代码导入代码的方便工具。
2. 使用我们建立的约定—ENV环境变量—我们获取当前运行的环境的名称。
3. 如果没有设置环境，我们就选择development作为默认设置，但是如前所述，这个决定将根据系统的不同而有所不同。
我们甚至可以考虑阻止应用程序启动，除非定义了这个变量。下面是一个这样的例子:
4. 接下来我们使用importlib.import_module函数将包含特定环境代码的模块加载到局部变量module中。
5. 最后，我们更新这个模块的globals，将development.py文件中设置合并到其中。
6. 最终，你将看到一些便利的工具(a-la Rails)，使基于环境切换具体的逻辑变得更加容易。它们作为函数保存，以便将实现隔离到此模块，而不是隔离到使用它的任何地方。
这种方法深受Ruby on Rails配置的启发，它实现了一个非常相似的外观，只是底层实现有所不同。
为了提供另一个实际的例子，以下是本网站的配置:
首先，这是我的config目录的确切目录结构:
base.py包含静态配置:
在development.py中，站点标题会被覆盖，这样，当我在编辑的时候，我就知道我正在查看的是一个本地副本。我还定义了一些本地的Redis配置，它们与Production有很大的不同。
最后，为了演示如何在应用程序的其他地方使用这个设置，我们来看看Redis连接是如何建立的:
注意最后一行:RedisManager.from_config()用于隔离关注点。RedisManager的其余部分不知道config中的数据是什么样子的，也不需要知道。这是配置层和系统其余部分之间的一个切换点。
我在所有的Python项目中都使用了这种方法，但还没有发现这种方法(或其变体)不起作用的情况。
总而言之，这种方法并不是很吸引人，而这正是我们在构建可靠、可维护和高效的系统时所想要的。使用一些简单的旧Python和几行特殊代码，我们就已经在我们的系统配置中释放了大量的灵活性和强大功能。
