对于分层和可继承配置来说，最好的 Perl 模块是什么？
如果我有一个新建项目，那么基于 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
我也想要一匹小马;)
If I have a greenfield project, what is the best practice Perl based configuration module to use?
There will be a Catalyst app and some command line scripts. They should share the same configuration.
Some features I think I want ...
Hierarchical Configurations to cleanly maintain different development and live settings.
I'd like to define "global" configurations once (eg, results_per_page => 20), have those inherited but override-able by my dev/live configs.
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
When I deploy a project to a new server, or branch/fork/copy it somewhere new (eg, a new development instance), I want to (one time only) set which configuration set/file to use, and then all future updates are automatic.
I'd envisage this could be achieved with a symlink:
git clone example.com:/var/git/my_project . # or any equiv vcs
cd my_project/etc
ln -s live.config to_use.config
Then in the future
git pull # or any equiv vcs
I'd also like something that akin to FindBin, so that my configs can either use absolute paths, or relative to the current deployment. Given
/home/me/development/project/
bin
lib
etc/config
where /home/me/development/project/etc/config contains:
tmpl_dir: templates/
when my perl code looks up the tmpl_dir configuration it'll get:
/home/me/development/project/templates/
But on the live deployment:
/var/www/project/
bin
lib
etc/config
The same code would magically return
/var/www/project/templates/
Absolute values in the config should be honoured, so that:
apache_config: /etc/apache2/httpd.conf
would return "/etc/apache2/httpd.conf" in all cases.
Rather than a FindBin style approach, an alternative might be to allow configuration values to be defined in terms of other configuration values?
tmpl_dir: $base_dir/templates
I'd also like a pony ;)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
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_.yml （它们都略有不同。 ..)。这样，我的所有配置都在 SVN 中，我只需要一个
ln -s步骤来手动配置服务器。Catalyst::Plugin::ConfigLoader supports multiple overriding config files. If your Catalyst app is called
MyApp, then it has three levels of override: 1)MyApp.pmcan have a__PACKAGE__->config(...)directive, 2) it next looks forMyApp.ymlin the main directory of the app, 3) it looks forMyApp_local.yml. Each level may override settings in each other level.In a Catalyst app I built, I put all of my immutable settings in
MyApp.pm, my debug settings inMyApp.yml, and my production settings inMyApp_<servertype>.ymland then symlinkedMyApp_local.ymlto point atMyApp_<servertype>.ymlon each deployed server (they were all a little different...).That way, all of my config was in SVN and I just needed one
ln -sstep to manually config a server.Perl 最佳实践 会针对您想要的内容发出警告。 它指出配置文件应该简单并避免您想要的那种巴洛克式功能。 它继续推荐三个模块（都不是 Core Perl）： Config::一般，Config::Std，和 Config::Tiny。
这背后的一般原理是，配置文件的编辑往往是由非程序员完成的，配置文件越复杂，他们就越有可能搞砸。
综上所述，您可以查看 YAML。 它提供了功能齐全、人类可读的
*序列化格式。 我相信目前推荐的 Perl 解析器是 YAML::XS。 如果您确实走这条路，我建议您编写一个配置工具供最终用户使用，而不是让他们直接编辑文件。ETA：根据 Chris Dolan 的回答，听起来 YAML 是适合您的方法，因为 Catalyst 已经在使用它（.yml 是 YAML 文件的事实上的扩展名）。
*我听到有人抱怨盲人可能会遇到困难Perl Best Practices warns against exactly what you want. It states that config files should be simple and avoid the sort of baroque features you desire. It goes on to recommend three modules (none of which are Core Perl): Config::General, Config::Std, and Config::Tiny.
The general rational behind this is that the editing of config files tends to be done by non-programmers and the more complicated you make your config files, the more likely they will screw them up.
All of that said, you might take a look at YAML. It provides a full featured, human readable
*, serialization format. I believe the currently recommend parser in Perl is YAML::XS. If you do go this route I would suggest writing a configuration tool for end users to use instead of having them edit the files directly.ETA: Based on Chris Dolan's answer it sounds like YAML is the way to go for you since Catalyst is already using it (.yml is the de facto extension for YAML files).
*I have heard complaints that blind people may have difficulty with itYAML 对于配置来说是令人讨厌的 - 它对非程序员不友好，部分原因是 pod 中的 yaml 从定义上来说是损坏的，因为它们都以不同的方式依赖于空白。 这解决了 Config::General 的主要问题。 我过去用 C::G 编写了一些相当复杂的配置文件，它在语法要求等方面确实不妨碍您。除此之外，Chris 的建议似乎是关于金钱的。
YAML is hateful for config - it's not non-programmer friendly partly because yaml in pod is by definition broken as they're both white-space dependent in different ways. This addresses the main problem with Config::General. I've written some quite complicated config files with C::G in the past and it really keeps out of your way in terms of syntax requirements etc. Other than that, Chris' advice seems on the money.