使用Python文件作为配置文件有多么糟糕的主意？

我一直使用JSON文件配置应用程序。我从编写大量Java时就开始使用它们，现在我主要从事服务器端和数据科学Python开发，并且不确定JSON是否是正确的选择。

我已经看到Celery使用实际的Python文件进行配置。最初我对此持怀疑态度。但是，使用简单的Python数据结构进行配置的想法开始对我产生影响。一些优点：

• 数据结构将与我通常在其中进行编码的结构相同。因此，我无需改变心态。
• 我的IDE（PyCharm）了解配置和代码之间的联系。Ctrl+ B使您可以轻松地在配置和代码之间跳转。
• 我不需要使用IMO不必要的严格JSON。我在看你双引号，没有结尾的逗号，也没有评论。
• 我可以在正在使用的应用程序中编写测试配置，然后轻松将它们移植到配置文件，而无需进行任何转换和JSON解析。
• 如果确实需要，可以在配置文件中执行非常简单的脚本。（尽管这应该非常非常有限。）

所以，我的问题是：如果我换了脚，我该如何射击自己的脚？

没有技能的最终用户将不会使用配置文件。对配置文件的任何更改当前都提交给Git，并作为连续部署的一部分部署到我们的服务器中。除非有紧急情况或正在开发中，否则无需进行手动配置更改。

（我考虑过YAML，但有关它的一些问题令我感到不适。因此，目前它不在美国的餐桌上。）

代替配置文件中使用脚本语言乍看起来不错：你有语言的全部功能可用，并且可以简单地eval()或者import它。实际上，有一些陷阱：

• 它是一种编程语言，需要学习。要编辑配置，您需要充分了解此语言。配置文件通常具有更简单的格式，更容易出错。

• 这是一种编程语言，这意味着配置可能难以调试。使用普通的配置文件，您可以查看它并查看为每个属性提供了哪些值。使用脚本，您可能需要先执行它才能查看值。

• 它是一种编程语言，这使得很难在配置和实际程序之间保持清晰的区分。有时您确实想要这种可扩展性，但是到那时，您可能宁愿在寻找一个真正的插件系统。

• 它是一种编程语言，这意味着配置可以执行编程语言可以执行的任何操作。因此，要么您正在使用沙盒解决方案，而该解决方案否定了该语言的许多灵活性，要么您对配置作者高度信任。

因此，如果您的工具的读者是开发人员，例如Sphinx config或Python项目中的setup.py，则使用脚本进行配置可能就可以了。其他具有可执行配置的程序是Shell（如Bash）和编辑器（如Vim）。

如果配置包含许多条件部分，或者提供回调/插件，则必须使用编程语言进行配置。直接使用脚本而不是eval（）-某些配置字段往往更易于调试（请考虑堆栈跟踪和行号！）。

如果您的配置如此重复，以至于您正在编写脚本以自动生成配置，那么直接使用编程语言也可能是一个好主意。但是，也许更好的配置数据模型可以消除对此类显式配置的需求？例如，如果配置文件可以包含稍后扩展的占位符，则可能会有所帮助。有时会看到的另一个功能是具有不同优先级的多个配置文件，它们可以相互覆盖，尽管这会带来一些自身的问题。

在大多数情况下，INI文件，Java属性文件或YAML文档更适合于配置。对于复杂的数据模型，XML也可能适用。正如您已经指出的那样，尽管JSON是一种很好的数据交换格式，但它在某些方面使它不适合用作人类可编辑的配置文件。

对amon的答案中的所有内容+1 。我想添加以下内容：

第一次要从用另一种语言编写的代码中导入相同的配置时，您会后悔使用Python代码作为配置语言。例如，如果代码是项目的一部分，并且是用C ++或Ruby编写的，或者需要其他配置来引入配置，则需要将Python解释器链接为一个库，或在Python协同进程中解析配置，这两种方式尴尬，困难或高昂的开销

今天导入此配置的所有代码都可能是用Python编写的，您也许认为明天也是如此，但是您确定吗？

您说您将在配置中使用逻辑（除了静态数据结构以外的任何方式）（如果有的话），这是很好的，但是如果有任何一点，将来您将很难撤消它，所以您可以移回声明性配置文件。

编辑记录：几个人对这个答案发表评论，说一个项目将完全成功地用另一种语言重新编写的可能性是多少。可以公平地说，可能很少看到完整的向后兼容重写。实际上，我想到的是同一项目的零碎片段（需要访问相同的配置）是以不同的语言编写的。例如，在C ++中提供堆栈以提高速度，在Python中提供批处理数据库清理，一些shell脚本作为胶水。因此，请为这种情况花点时间：)

其他答案已经非常好，我将在一些项目中介绍我的实际用法。

优点

它们大部分已经被阐明：

• 如果您使用的是Python程序，则解析起来很容易（eval）；它甚至可以自动用于更复杂的数据类型（在我们的程序中，我们具有几何点和变换，可以通过repr/ 很好地进行转储/加载eval）；
• 仅用几行代码创建一个“假配置”是微不足道的；
• 您拥有更好的结构，并且IMO的语法也比JSON更好（jeez甚至只是具有注释，而不必在字典键周围加上双引号是可读性的一大胜利）。

缺点

• 恶意用户可以执行您的主程序可以执行的任何操作；我认为问题不大，因为通常，如果用户可以修改配置文件，则他/她已经可以执行应用程序可以执行的任何操作；
• 如果您不再使用Python程序，现在就遇到了问题。尽管我们的几个配置文件保留了其原始应用程序的私有性，但其中一个特别用于存储由多个不同程序使用的信息，其中大多数程序当前都在C ++中，而这些程序现在都有一个共同使用的解析器，用于定义不明确的小程序。 Python的子集repr。这显然是一件坏事。
• 即使您的程序仍使用Python，也可以更改Python版本。假设您的应用是从Python 2开始的；经过大量测试后，您设法将其迁移到Python 3-不幸的是，您并未真正测试所有代码-您所有的配置文件都位于客户计算机上，是为Python 2编写的，而您没有真的没有控制权。除非您愿意捆绑/调用Python 2解释器，否则您甚至无法提供“兼容模式”来读取旧的配置文件（通常是针对文件格式进行的操作）！

• 即使您使用的是Python，从代码中修改配置文件也是一个真正的问题，因为……好吧，修改代码根本不是一件容易的事，尤其是语法丰富且不在LISP或类似语言中的代码。我们的一个程序有一个配置文件，它是Python，最初是手工编写的，但后来证明通过软件进行操作将很有用（一个特殊的设置是一系列的事情，使用GUI 可以更轻松地对其进行重新排序）。这是一个大问题，因为：

  • 即使只是执行parse→AST→rewrite往返也不是一件容易的事（您会注意到，提议的解决方案中有一半后来被标记为“过时，不使用，在所有情况下均不起作用”）；
  • 即使他们工作了，AST也太低级了；您通常对处理文件中执行的计算结果感兴趣，而不是对文件执行操作感兴趣；
  • 这使我们想到了一个简单的事实，即您不能只编辑您感兴趣的值，因为它们可能是由您无法通过代码理解/操纵的复杂计算生成的。

  将此与JSON，INI或（上帝禁止！）XML进行比较，在这种情况下，始终可以编辑和写回内存中的表示形式而不会丢失数据（XML，其中大多数DOM解析器可以在文本节点和注释节点中保留空格），或者至少会丢失某些格式（JSON，其中格式本身所允许的内容不超过您正在读取的原始数据）。

因此，像往常一样，没有明确的解决方案。我目前在该问题上的政策是：

• 如果配置文件是：

  • 当然，对于Python应用程序来说，它是私有的-例如，没有其他人会尝试读取它；
  • 手写
  • 来自受信任的来源；
  • 使用目标应用程序数据类型确实是一种奖励。

  Python文件可能是一个有效的主意；

• 如果相反：

  • 可能有其他一些应用程序从中读取；
  • 该文件可能会被某个应用程序（甚至是我的应用程序本身）编辑；
  • 由不受信任的来源提供。

  “仅数据”格式可能是一个更好的主意。

请注意，不需要做出单一选择-我最近编写了使用这两种方法的应用程序。我有一个几乎从未修改过的文件，该文件具有首次设置，手写设置以及可以从UI编辑的用于配置的JSON文件，这些设置具有获得不错的Python奖励的优势。

主要问题是：您是否希望配置文件使用某种图灵完整的语言（例如Python）？如果您确实希望这样做，则还可以考虑嵌入其他（如Turnle完整的）脚本语言，例如Guile或Lua（因为与Python相比，使用或嵌入它们可能被认为“更简单”；请阅读“ 扩展和嵌入Python）。我不会讨论进一步的（因为-EG其他答案由阿蒙 -讨论了深），但请注意，在你的应用程序中嵌入的脚本语言是一个重大的架构选择，你应该考虑的非常早; 我真的不建议以后再做出选择！

可以通过“脚本”进行配置的程序的一个著名示例是GNU emacs编辑器（或专有领域中的AutoCAD）。因此请注意，如果您接受脚本编写，则某些用户最终会广泛使用该工具（可能会滥用），并制作成千上万行的脚本；因此，选择足够好的脚本语言非常重要。

但是（至少在POSIX系统上），您可能认为方便在初始化时动态计算配置“文件”（当然，将合理配置的负担留给了系统管理员或用户；实际上它是一种配置）来自某个文件或命令的文本）。为此，您可以简单地采用一种约定（并将其记录下来），即以a !或a 开头的配置文件路径|实际上是要作为管道读取的shell 命令。这使您的用户可以选择使用他最熟悉的“预处理器”或“脚本语言”。

^{（如果您接受动态计算的配置，则需要让用户信任安全问题）}

因此，在您的初始化代码中，您main将（例如）接受一些--config 参数 confarg并从中获取一些参数FILE*configf;。如果该参数以!（即(confarg[0]=='!')....）开头，则可以使用configf = popen(confarg+1, "r");并关闭该管道pclose(configf);。否则，您将使用configf=fopen(confarg, "r");并关闭该文件fclose(configf);（不要忘记进行错误检查）。参见pipe（7），popen（3），fopen（3）。对于以Python编码的应用程序，请阅读有关os.popen等的信息。

^{（文件还为希望通过名为的配置文件中的怪异用户!foo.config通过./!foo.config绕过popen上述特技）}

顺便说一句，这种技巧只是一种方便（避免要求高级用户例如编写一些shell脚本来生成配置文件）。如果用户要报告任何错误，则应将生成的配置文件发送给您...

注意，您还可以设计具有在初始化时使用和加载插件的功能的应用程序，例如使用dlopen（3）（并且您需要让用户信任该插件）。同样，这是一个非常重要的体系结构决策（您需要定义并提供有关这些插件和应用程序的相当稳定的API和约定）。

对于以脚本语言（如Python）编码的应用程序，您还可以接受一些用于eval或exec或类似基元的程序参数。同样，（高级）用户会担心安全问题。

关于您的配置文件中的文本格式（无论是产生或没有），我相信你大多需要记录它好（和一些特定格式的选择是不那么重要，但是我建议让您的用户能够把里面有一些跳过的注释）。你可以使用JSON（最好带些JSON解析器接受和跳过与通常的意见//，直至停产或/*... */...），或YAML或XML，或INI或你自己的事情。解析配置文件相当容易（并且您会发现许多与该任务相关的库）。

除了amon的答案外，您是否考虑过替代方案？JSON可能比您需要的更多，但是由于上述原因，Python文件将来可能会给您带来问题。

但是，Python已经具有用于非常简单的配置语言的配置解析器，可以满足您的所有需求。该ConfigParser模块实现了一个简单的配置语言。

我使用某些知名软件工作了很长时间，该软件的配置文件用TCL编写，因此这个想法并不新鲜。这非常有效，因为不了解该语言的用户仍然可以使用单个set name value语句来编写/编辑简单的配置文件，而更高级的用户和开发人员可以以此来获取复杂的技巧。

我认为“配置文件可能难以调试”不是一个有效的问题。只要您的应用程序不强迫用户编写脚本，您的用户就可以始终在其配置文件中使用简单的分配，与JSON或XML相比，这几乎很难解决。

重写配置是一个问题，尽管它看起来还不算糟糕。更新任意代码是不可能的，但是从文件中加载配置，更改并保存回去是可以的。基本上，如果您在非只读的配置文件中执行一些脚本编写，则一旦保存该文件，您将得到等价的set name value语句列表。一个很好的暗示，即将发生这种情况的是文件开头的“请勿编辑”注释。

要考虑的一件事是，您的配置文件将无法通过基于regex的简单工具可靠地读取sed，但据我了解，当前的JSON文件已经不是这种情况了，因此不会有太多损失。

只需确保在执行配置文件时使用适当的沙箱技术即可。

除了这里其他好的答案的所有有效点（哇，他们甚至提到了图灵完备的概念），实际上还有很多可靠的实际原因，即使在使用Python时，也不使用Python文件作为配置-唯一的项目。

1. 从技术上讲，Python源文件中的设置是可执行源代码的一部分，而不是只读数据文件。如果走这条路，通常会这样做import config，因为这种“便利”可能是人们首先开始使用Python文件作为配置的主要原因之一。现在，您倾向于将该config.py提交到您的存储库中，否则最终用户在首次尝试运行程序时会遇到令人困惑的ImportError。

2. 假设您实际上将config.py提交到您的仓库中，那么您的团队成员可能在不同的环境中具有不同的设置。想像一下，有一天某位成员不小心将其本地配置文件提交到了仓库中。

3. 最后但并非最不重要的一点是，您的项目可能在配置文件中具有密码。（这本身是值得商practice的做法，但是还是会发生这种情况。）而且，如果您的配置文件存在于回购中，则有将证书提交到公共回购中的风险。

现在，使用仅数据配置文件（例如通用JSON格式）可以避免上述所有3个问题，因为您可以合理地要求用户提供自己的config.json并将其输入到程序中。

PS：的确，JSON有很多限制。OP提到的2个局限性可以通过一些创造力来解决。

• 如何将注释放入JSON文件（正确）

• 而且我通常会使用一个占位符来绕开尾部的逗号规则。像这样：

  {
      "foo": 123,
      "bar": 456,
      "_placeholder_": "all other lines in this file can now contain trailing comma"
  }