分层和可继承配置的最佳 Perl 模块是什么？答案

【问题标题】：What's the best Perl module for hierarchical and inheritable configuration?分层和可继承配置的最佳 Perl 模块是什么？
【发布时间】：2009-03-15 13:01:06
【问题描述】：

如果我有一个新建项目，使用基于 Perl 的配置模块的最佳实践是什么？

会有一个 Catalyst 应用程序和一些命令行脚本。它们应该共享相同的配置。

我想我想要的一些功能......

分层配置以干净地维护不同的开发和实时设置。

我想定义一次“全局”配置（例如，results_per_page => 20），让那些继承但可以被我的开发/实时配置覆盖。

Global:
  results_per_page: 20
  db_dsn: DBI:mysql;
  db_name: my_app
Dev:
  inherit_from: Global
  db_user: dev
  db_pass: dev
Dev_New_Feature_Branch:
  inherit_from: Dev
  db_name: my_app_new_feature
Live:
  inherit_from: Global
  db_user: live
  db_pass: secure

当我将项目部署到新服务器或将其分支/分叉/复制到新的地方（例如，新的开发实例）时，我想（仅一次）设置要使用的配置集/文件，然后所有未来的更新都是自动的。

我想这可以通过符号链接来实现：

git clone example.com:/var/git/my_project . # or any equiv vcs
cd my_project/etc
ln -s live.config to_use.config

那么在未来

git pull # or any equiv vcs

我还想要类似于 FindBin 的东西，这样我的配置既可以使用绝对路径，也可以相对于当前部署。给定

/home/me/development/project/
  bin
  lib
  etc/config

/home/me/development/project/etc/config 包含：

tmpl_dir: templates/

当我的 perl 代码查找 tmpl_dir 配置时，它会得到：

/home/me/development/project/templates/

但是在实时部署中：

/var/www/project/
  bin
  lib
  etc/config

同样的代码会神奇地返回

/var/www/project/templates/

应该尊重配置中的绝对值，以便：

apache_config: /etc/apache2/httpd.conf

在所有情况下都会返回“/etc/apache2/httpd.conf”。

除了 FindBin 样式的方法，另一种方法可能是允许根据其他配置值定义配置值？

tmpl_dir: $base_dir/templates

我也想要一匹小马；）

【问题讨论】：

标签： perl configuration configuration-files config

【解决方案1】：

Catalyst::Plugin::ConfigLoader 支持多个覆盖配置文件。如果您的 Catalyst 应用程序名为 MyApp，那么它具有三个覆盖级别：1) MyApp.pm 可以有一个 __PACKAGE__->config(...) 指令，2) 它接下来会在应用程序的主目录中查找 MyApp.yml，3)它寻找MyApp_local.yml。每个级别都可以覆盖其他级别的设置。

在我构建的 Catalyst 应用程序中，我将所有不可变设置放在 MyApp.pm 中，将调试设置放在 MyApp.yml 中，将生产设置放在 MyApp_<servertype>.yml 中，然后将 MyApp_local.yml 符号链接到 MyApp_<servertype>.yml在每个部署的服务器上（它们都有点不同......）。

这样，我所有的配置都在 SVN 中，我只需要一个 ln -s 步骤来手动配置服务器。

【讨论】：

【解决方案2】：

Perl Best Practices 会针对您想要的内容发出警告。它指出配置文件应该简单并且避免你想要的那种巴洛克式的特性。它继续推荐三个模块（都不是 Core Perl）：Config::General、Config::Std 和 Config::Tiny。

这背后的一般原因是，配置文件的编辑往往由非程序员完成，您制作的配置文件越复杂，他们就越有可能搞砸。

说了这么多，你可以看看YAML。它提供了功能齐全、人类可读的* 序列化格式。我相信目前在 Perl 中推荐的解析器是YAML::XS。如果您确实走这条路，我建议您编写一个配置工具供最终用户使用，而不是让他们直接编辑文件。

ETA：根据 Chris Dolan 的回答，听起来 YAML 是适合您的方式，因为 Catalyst 已经在使用它（.yml 是 YAML 文件的事实上的扩展名）。

*我听说盲人可能有困难

【讨论】：

【解决方案3】：

YAML 对 config 是可恨的——它不是非程序员友好的，部分原因是 pod 中的 yaml 根据定义被破坏，因为它们都以不同的方式依赖于空白。 This 解决了 Config::General 的主要问题。过去我用 C::G 编写了一些相当复杂的配置文件，它在语法要求等方面确实不妨碍您。除此之外，Chris 的建议似乎很划算。

【讨论】：