Question

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

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

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

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

我想定义一次“全局”配置（例如，results_per_page =＆gt; 20），继承那些但我的dev / live配置可以覆盖的配置。

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

我也喜欢小马;）

Answer 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中，然后符号链接{{1在每个已部署的服务器上指向MyApp_local.yml（它们都有点不同......）。

这样，我的所有配置都在SVN中，我只需要一个MyApp_<servertype>.yml步骤来手动配置服务器。

Answer 2

Perl Best Practices警告你想要什么。它声明配置文件应该很简单，并避免使用您想要的巴洛克式功能。它继续推荐三个模块（其中没有一个是Core Perl）：Config::General，Config::Std和Config::Tiny。

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

所有这些都说，你可以看看YAML。它提供了一个功能齐全，人类可读的*序列化格式。我相信Perl目前推荐的解析器是YAML::XS。如果您选择这条路线，我建议您为最终用户编写配置工具，而不是直接编辑文件。

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

*我听到有人抱怨盲人可能会遇到困难

Answer 3

YAML对配置很讨厌 - 它不是非程序员友好的部分因为pod中的yaml定义是破坏的，因为它们都以不同的方式依赖于空白。 This解决了Config :: General的主要问题。我以前用C :: G编写了一些相当复杂的配置文件，它在语法要求等方面确实不受你的影响。除此之外，克里斯的建议似乎也在钱上。

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

3 个答案: