Qual é o melhor módulo Perl para configuração hierárquica e hereditária?

Question

Se eu tiver um projeto greenfield, que é o melhor módulo de configuração baseada na prática Perl para uso?

Haverá um aplicativo Catalyst e alguns scripts de linha de comando. Eles devem compartilhar a mesma configuração.

Algumas características que eu acho que eu quero ...

configurações hierárquicas para manter limpa desenvolvimento diferente e configurações ao vivo.

Eu gostaria de definir configurações "globais" uma vez (por exemplo, results_per_page => 20), ter essas configurações herdadas, mas override-capazes pelo meu dev / ao vivo.

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 eu implantar um projeto para um novo servidor, ou filial / garfo / copiá-lo em algum lugar novo (por exemplo, uma nova instância de desenvolvimento), eu quero (apenas uma vez) Conjunto qual conjunto de configuração / arquivo para uso, e depois todas as futuras atualizações são automáticas.

Eu prever isso poderia ser conseguido com um link simbólico:

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

Em seguida, no futuro

git pull # or any equiv vcs

Eu também gostaria algo que semelhante a FindBin, de modo que minhas configurações pode usar caminhos absolutos ou em relação à implantação atual. Dada

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

onde / home / me / desenvolvimento / projecto / etc / config contém:

tmpl_dir: templates/

quando meus olhares código Perl a configuração tmpl_dir ele vai ficar:

/home/me/development/project/templates/

Mas sobre a implantação ao vivo:

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

O mesmo código seria magicamente voltar

/var/www/project/templates/

Os valores absolutos na configuração devem ser honrados, de modo que:

apache_config: /etc/apache2/httpd.conf

voltaria "/etc/apache2/httpd.conf" em todos os casos.

Em vez de uma abordagem estilo FindBin, uma alternativa poderia ser a de permitir que os valores de configuração a ser definida em termos de outros valores de configuração?

tmpl_dir: $base_dir/templates

Eu também gostaria um pônei;)

Answer 1

Catalisador :: Plugin :: ConfigLoader suporta múltiplos imperiosas arquivos de configuração . Se seu aplicativo Catalisador é chamado MyApp, então ele tem três níveis de substituição: 1) MyApp.pm pode ter uma directiva __PACKAGE__->config(...), 2) próximos procura MyApp.yml no diretório principal do aplicativo, 3) ele procura MyApp_local.yml. Cada nível pode substituir as configurações em outro nível.

Em um aplicativo Catalisador eu construí, eu coloquei todas as minhas configurações imutáveis ??em MyApp.pm, as minhas configurações de depuração em MyApp.yml, e as minhas definições de produção em MyApp_<servertype>.yml e, em seguida, simbolicamente MyApp_local.yml ao ponto em MyApp_<servertype>.yml em cada servidor implantado (eram todos um pouco diferente ...).

Dessa forma, toda a minha configuração estava no SVN e eu só precisava de um passo ln -s config manualmente um servidor.

Answer 2

Perl Best Practices adverte contra exatamente o que você quer. Ele afirma que os arquivos de configuração deve ser simples e evitar o tipo de características barrocas que você deseja. Vai ao ponto de recomendar três módulos (nenhum dos quais é Núcleo Perl): Config :: geral, config :: Std , e config :: minúsculo .

O racional geral por trás disso é que a edição de arquivos de configuração tende a ser feito por não-programadores e quanto mais complicado você fazer seus arquivos de configuração, o mais provável que eles vão estragar-los.

Tudo isso dito, você pode dar uma olhada em YAML . Ele fornece uma readable* humana, formato cheio de recursos, serialização. Eu acredito que o analisador atualmente recomendamos em Perl é YAML :: XS . Se você vai fazer esta rota eu sugeriria escrevendo uma ferramenta de configuração para os usuários finais para usar em vez de tê-los editar os arquivos diretamente.

ETA:. Com base na resposta de Chris Dolan parece YAML é o caminho a percorrer para você desde Catalisador já está usando (.yml é a extensão de facto para arquivos YAML)

* Tenho ouvido queixas de que pessoas cegas podem ter dificuldade com ele

Answer 3

YAML é odioso para config - não é programador não amigável em parte porque yaml no pod é, por definição quebrado como eles são dependentes de diferentes maneiras white-space. Este endereços o principal problema com Config :: Geral. Eu escrevi alguns arquivos de configuração bastante complicado com C :: G no passado e realmente mantém fora do seu caminho em termos de requisitos de sintaxe etc. Outros do que isso, o conselho de Chris parece sobre o dinheiro.