Qual è il miglior modulo Perl per la configurazione gerarchica ed ereditabile?

Question

Se si dispone di un progetto greenfield, quale è il modulo di configurazione basato su Perl con la migliore pratica da utilizzare?

Ci sarà un'app Catalyst e alcuni script da riga di comando. Dovrebbero condividere la stessa configurazione.

Alcune caratteristiche penso che voglio ...

configurazioni gerarchiche per mantenere in modo pulito sviluppo diverso e le impostazioni dal vivo.

Mi piacerebbe definire una volta le configurazioni "globali" (ad es. Results_per_page => 20), avere quelle ereditate ma sovrascrivibili dalle mie 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 

Quando schiero un progetto per un nuovo server, o il ramo/forchetta/copia da qualche parte nuova (ad esempio, una nuova istanza di sviluppo), voglio (una sola volta) insieme che set di configurazione/file utilizzare e quindi tutti gli aggiornamenti futuri sono automatici.

avrei prevedo Ciò potrebbe essere realizzato con un link simbolico:

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

Poi in futuro

git pull # or any equiv vcs 

mi piacerebbe anche qualcosa che di simile a FindBin, in modo che i miei file di configurazione può utilizzare i percorsi assoluti o relativi alla distribuzione corrente. Dato

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

dove/home/me/sviluppo/progetto/etc/config contiene:

tmpl_dir: templates/ 

quando il mio codice Perl guarda la configurazione tmpl_dir otterrà:

/home/me/development/project/templates/ 

Ma sulla distribuzione dal vivo:

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

Lo stesso codice avrebbe magicamente tornare

/var/www/project/templates/ 

valori assoluti nella configurazione dovrebbe essere onorato, in modo tale che:

apache_config: /etc/apache2/httpd.conf 

sarebbero tornati "/etc/apache2/httpd.conf" in tutti i casi.

Piuttosto che un approccio in stile FindBin, un'alternativa potrebbe essere quella di consentire la definizione dei valori di configurazione in termini di altri valori di configurazione?

tmpl_dir: $base_dir/templates 

Mi piacerebbe anche un pony;) ​​

Answer 1

Catalyst::Plugin::ConfigLoader supporta più file di configurazione di primaria importanza. Se la tua app Catalyst è denominata MyApp, ha tre livelli di sostituzione: 1) MyApp.pm può avere una direttiva __PACKAGE__->config(...), 2) successivamente cerca MyApp.yml nella directory principale dell'app, 3) cerca MyApp_local.yml. Ogni livello può sovrascrivere le impostazioni in ogni altro livello.

In un'applicazione Catalyst ho costruito, ho messo tutte le mie impostazioni immutabili nel MyApp.pm, le mie impostazioni di debug in MyApp.yml, e le mie impostazioni di produzione in MyApp_<servertype>.yml e poi collegato simbolicamente MyApp_local.yml per puntare a MyApp_<servertype>.yml su ogni server distribuito (erano tutti un poco diverso ...).

In questo modo, tutta la mia configurazione era in SVN e avevo solo bisogno di un passo ln -s per configurare manualmente un server.

Answer 2

Perl Best Practices segnala esattamente ciò che si desidera. Afferma che i file di configurazione dovrebbero essere semplici ed evitare il tipo di caratteristiche barocche che desideri. Continua a raccomandare tre moduli (nessuno dei quali è Core Perl): Config::General, Config::Std e Config::Tiny.

Il razionale generale dietro questo è che la modifica dei file di configurazione tende a essere eseguita dai non programmatori e più è complicato creare i file di configurazione, più è probabile che li rovinino.

Tutto ciò detto, si potrebbe dare un'occhiata a YAML. Fornisce un formato di serializzazione completo, leggibile dall'uomo *, in formato serializzazione. Credo che il parser attualmente raccomandato in Perl sia YAML::XS. Se segui questa strada, ti suggerirei di scrivere uno strumento di configurazione da utilizzare per gli utenti finali invece di doverli modificare direttamente.

ETA: Sulla base della risposta di Chris Dolan, sembra che YAML sia la soluzione ideale poiché Catalyst lo sta già utilizzando (.yml è l'estensione de facto per i file YAML).

* Ho sentito lamentele che non vedenti possono avere difficoltà con esso

Answer 3

YAML è odioso per config - non è non-programmatore amichevole in parte perché YAML in baccello è per definizione rotto come sono entrambi white-space dipende in diversi modi. This affronta il problema principale con Config :: General. Ho scritto alcuni file di configurazione abbastanza complicati con C :: G in passato e mi tiene davvero alla larga in termini di requisiti di sintassi, ecc. A parte questo, i consigli di Chris sembrano in the money.