Was ist die beste Perl-Modul für hierarchische und vererbbaren Konfiguration?

Question

Wenn ich ein greenfield-Projekt, was ist die beste Praxis Perl-basierten Konfigurations-Modul zu verwenden?

Es wird eine Catalyst-app und einige Kommandozeilen-Skripte.Sie sollte teilen die gleiche Konfiguration.

Einige Funktionen, die ich glaube, ich will ...

Hierarchische Konfigurationen sauber zu halten verschiedenen Entwicklungs-und live-Einstellungen.

Ich möchte define "global" - Konfigurationen einmal (zB results_per_page => 20), habe diese geerbt, aber überschreiben können, indem Sie meine 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

Wenn ich ein Projekt bereitstellen, um einen neuen server, oder branch/fork/kopieren Sie es irgendwo neues (z.B. eine neue Entwicklung Instanz), ich will (nur ein mal) set die Konfiguration set/ - Datei zu verwenden, und dann werden alle zukünftigen updates sind automatisch.

Ich würde vorsehen erreicht werden könnte dies mit einem symlink:

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

Dann in der Zukunft

git pull # or any equiv vcs

Ich möchte auch etwas, das ähnlich FindBin, so dass meine configs können entweder absolute Pfade oder relativ zum aktuellen Einsatz.Gegeben

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

wo /home/me/development/project/etc/config enthält:

tmpl_dir: templates/

wenn mein perl-code sieht bis die tmpl_dir Konfiguration erhalten:

/home/me/development/project/templates/

Aber auf die live-Bereitstellung:

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

Der gleiche code magisch zurückkehren würde

/var/www/project/templates/

Absolute Werte in der config sollte geehrt werden, so dass:

apache_config: /etc/apache2/httpd.conf

würde Rückkehr "/etc/apache2/httpd.conf" in allen Fällen.

Anstatt eine FindBin-Stil Ansatz, eine alternative könnte sein, damit die Konfiguration Werte definiert werden in Bezug auf andere Konfigurationswerte?

tmpl_dir: $base_dir/templates

Ich möchte auch ein pony ;)

Answer 1

Catalyst::Plugin::ConfigLoader unterstützt mehrere übergeordnete config-Dateien.Wenn Ihr Katalysator-app aufgerufen wird MyApp, dann es hat drei Ebenen von überschreiben:1) MyApp.pm können __PACKAGE__->config(...) Richtlinie 2) in der nächsten sucht MyApp.yml im Haupt-Verzeichnis der app, 3) sieht es für MyApp_local.yml.Jede Ebene möglicherweise überschreiben die Einstellungen in jedem anderen Ebene.

In eine Catalyst-app, die ich gebaut habe ich alle meine unveränderlichen Einstellungen MyApp.pm, mein debug-Einstellungen im MyApp.yml, und meine Einstellungen in der Produktion MyApp_<servertype>.yml und dann symlinked MyApp_local.yml zeigen MyApp_<servertype>.yml auf jedem server bereitgestellt (Sie waren alle ein wenig anders...).

So, alle meine config wurde in SVN und ich brauchte nur eine ln -s Schritt manuell config server.

Answer 2

Perl Best Practices warnt davor, die genau was Sie wollen.Es besagt, dass die config-Dateien sollte einfach und vermeiden Sie die Art von Barock-Funktionen, die Sie wünschen.Es geht weiter zu empfehlen drei Module (keine Core-Perl): Config::General, Config::Std, und Config::Tiny.

Die Allgemeine rationale dahinter ist, dass die Bearbeitung von config-Dateien, die dazu neigt, zu tun durch nicht-Programmierer, und die mehr kompliziert machen Sie aus Ihrem config-Dateien, die Wahrscheinlichkeit, dass Sie Schraube Sie an.

All das sagte, dass Sie vielleicht nehmen Sie ein Aussehen an YAML.Es bietet eine voll ausgestattete, human-readable*, Serialisierung-format.Ich glaube, der derzeit empfehlen parser in Perl YAML::XS.Wenn Sie diesen Weg gehen, würde ich vorschlagen, schreiben ein Konfigurations-tool für end-Benutzer zu verwenden, anstatt Sie Bearbeiten die Dateien direkt.

ETA:Basierend auf Chris Dolan ' s Antwort, es klingt wie YAML ist der Weg zu gehen für Sie, da Katalysator bereits verwendet werden (.yml ist die de-facto-Erweiterung für YAML-Dateien).

* Ich habe Beschwerden gehört, dass blinde Menschen haben Schwierigkeiten mit es

Answer 3

YAML ist abscheulich für config - es ist nicht nicht-Programmierer freundlich, Teils, weil yaml in den pod per definition ist gebrochen, als Sie die beiden weißen Flächen angewiesen auf unterschiedliche Weise. Diese Adressen der Haupt-problem mit Config::General.Ich habe geschrieben, einige ziemlich komplizierte Konfigurationsdateien mit C::G in der Vergangenheit und es hat mich immer aus dem Weg, der in Bezug auf die syntax Anforderungen etc.Andere als, dass, Chris' Rat scheint auf dem Geld.