2009-03-15 7 views
5

グリーンフィールドプロジェクトがある場合、使用するPerlベースの設定モジュールは何ですか?階層的で継承可能な設定に最適なPerlモジュールは何ですか?

Catalystアプリケーションといくつかのコマンドラインスクリプトがあります。同じ構成を共有する必要があります。

私は私がしたいと思ういくつかの機能...きれいに異なる開発やライブの設定を維持するために

階層構成。

私はかつて、「グローバル」構成を定義したいと思います(例えば、results_per_page => 20)、これらの継承されてきたが、上書き可能な私のdevの/ライブの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 

新しい(例えば、新開発インスタンス)私は新しいサーバーにプロジェクトを配置、または支店/フォーク/どこかでそれをコピーすると、私は(一度だけ)するセットされた構成のセット/ファイルへ将来のすべての更新は自動的に行われます。

私は、これはシンボリックリンクで達成することができ想定たい:

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に似て何か欲しい、私のconfigsができるように、絶対パスを使用するか、現在のデプロイメントに対して相対パスを使用します。

/ホーム/私/開発/プロジェクトの/ etc/configには含まれてい
/home/me/development/project/ 
    bin 
    lib 
    etc/config 

を考える:私のPerlコードがtmpl_dirコンフィギュレーションを検索するとき

tmpl_dir: templates/ 

それが得られます。

/home/me/development/project/templates/ 

ライブ配信の場合:

/var/www/project/ 
    bin 
    lib 
    etc/config 
apache_config: /etc/apache2/httpd.conf 

は、すべてのケースで「/etc/apache2/httpd.conf」を返します:よう同じコードが魔法のように、光栄されなければならない設定に

/var/www/project/templates/ 

絶対値を返します。

よりもむしろFindBinスタイルのアプローチ、代替手段によって設定値が他の設定値に基づいて定義することができるようになるのでしょうか?

tmpl_dir: $base_dir/templates 

私もポニーたい;)

答えて

9

Catalyst::Plugin::ConfigLoaderは、複数のオーバーライドの設定ファイルをサポートしています。あなたのCatalystアプリがMyAppと呼ばれている場合、それはディレクティブを持つことができるMyApp.pm、2)次にアプリケーションのメインディレクトリにMyApp.ymlを探します、3)それはMyApp_local.ymlを探します。各レベルは、お互いのレベルの設定を上書きすることができます。私が構築された触媒のアプリで

、私はその後、私のデバッグ設定 MyApp.ymlで、かつ MyApp_<servertype>.ymlの私の制作設定、 MyApp.pmに私の不変の設定のすべてを入れて、それぞれ配置されたサーバ上の MyApp_<servertype>.ymlを指すように MyApp_local.ymlをシンボリックリンク(彼らがいたすべての少し違う...)。

このように、私の設定はすべてSVNに入っていて、サーバを手動で設定するにはln -sステップが必要でした。

6

Perl Best Practicesは、あなたが欲しいものを正確に警告します。それは、設定ファイルがシンプルで、あなたが望むバロック様式の種類を避けるべきだと述べています。それは、3つのモジュール(どれもCore Perlではない):Config::GeneralConfig::Std、およびConfig::Tinyを推奨しています。

これは、設定ファイルの編集が非プログラマによって行われる傾向があり、設定ファイルが複雑になればなるほど、それらを取り締まる可能性が高くなるということです。

これらのすべては、YAMLをご覧ください。これは、フル機能の人間が読める*、シリアライズ形式を提供します。私は現在、Perlの推奨パーサーはYAML::XSだと信じています。この道を行くなら、エンドユーザーがファイルを直接編集するのではなく、使用するための構成ツールを書くことをお勧めします。

ETA:Chris Dolanの回答によれば、Catalystはすでにそれを使用しているので、YAMLはあなたのための方法です(.ymlはYAMLファイルの事実上の拡張です)。

*私は人々がYAMLは設定のための憎いです

2

ことの難しさを有することができるブラインド苦情を聞いたことがある - 彼らは空白の両方だとしてポッドでYAMLが定義によって壊れているので、それは部分的に非プログラマフレンドリーではありません異なる方法で依存しています。 Thisは、Config :: Generalの主な問題を解決します。私は過去にC :: Gでかなり複雑な設定ファイルを書いてきましたが、シンタックス要件などの点ではあなたのやり方を邪魔することはありませんでした。

関連する問題