Quel est le meilleur module Perl pour la configuration hiérarchique et héritable?

Question

Si j'ai un projet en arrière-plan, quelle est la meilleure pratique de configuration d'un module de configuration basé sur Perl?

Il y aura une application Catalyst et des scripts de ligne de commande. Ils doivent partager la même configuration.

Certaines fonctionnalités que je pense que je veux ...

Configurations hiérarchiques pour conserver de manière propre différents paramètres de développement et d’utilisation réelle.

J'aimerais définir " global " Une fois les configurations (par exemple, results_per_page = > 20), celles-ci sont héritées mais peuvent être remplacées par mes conf / dev / live.

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

Lorsque je déploie un projet sur un nouveau serveur, ou branche / branche / le copie ailleurs (par exemple, une nouvelle instance de développement), je souhaite (une fois seulement) définir le jeu / fichier de configuration à utiliser, puis toutes les mises à jour futures sont automatiques.

Je pense que cela pourrait être réalisé avec un lien symbolique:

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

Ensuite, dans le futur

git pull # or any equiv vcs

Je voudrais aussi quelque chose qui ressemble à FindBin, de sorte que mes configs puissent utiliser des chemins absolus ou relatifs au déploiement actuel. Étant donné

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

où / home / me / développement / projet / etc / config contient:

tmpl_dir: templates/

lorsque mon code Perl recherche la configuration de tmpl_dir, il obtiendra:

/home/me/development/project/templates/

Mais sur le déploiement en direct:

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

Le même code renverrait comme par magie

/var/www/project/templates/

Les valeurs absolues dans la configuration doivent être respectées, de sorte que:

apache_config: /etc/apache2/httpd.conf

renverrait " /etc/apache2/httpd.conf " dans tous les cas.

Plutôt qu'une approche de style FindBin, une alternative pourrait être de permettre aux valeurs de configuration d'être définies en termes d'autres valeurs de configuration?

tmpl_dir: $base_dir/templates

Je voudrais aussi un poney;)

Answer 1

Catalyst :: Plugin :: ConfigLoader prend en charge plusieurs fichiers de configuration prioritaires. . Si votre application Catalyst s'appelle MyApp, elle comporte trois niveaux de substitution: 1) MyApp.pm peut avoir une directive __PACKAGE__->config(...), 2) elle recherche ensuite MyApp.yml dans le répertoire principal de l'application, 3) il cherche MyApp_local.yml. Chaque niveau peut remplacer les paramètres de chaque autre niveau.

Dans une application Catalyst que j'ai créée, j'ai placé tous mes paramètres immuables dans MyApp_<servertype>.yml, mes paramètres de débogage dans ln -s et mes paramètres de production dans <=>, puis un lien symbolique <=> pour pointer vers <=> sur chaque serveur déployé (ils étaient tous un peu différents ...).

Ainsi, toute ma configuration était en SVN et il me fallait juste une <=> étape pour configurer manuellement un serveur.

Answer 2

Les Meilleures pratiques Perl vous avertissent de ce que vous souhaitez exactement. Il indique que les fichiers de configuration doivent être simples et éviter le type de caractéristiques baroques que vous désirez. Il recommande ensuite trois modules (dont aucun n'est Core Perl): Config :: Général , Config :: Std , et Config :: Tiny .

La raison générale derrière tout cela est que l'édition des fichiers de configuration a tendance à être effectuée par des non-programmeurs et que plus vous créez des fichiers de configuration compliqués, plus ils risquent de les rater.

Cela étant dit, vous pouvez consulter YAML . Il fournit un format de sérialisation complet, lisible par l’homme *. Je crois que l’analyseur actuellement recommandé en Perl est YAML :: XS . Si vous choisissez cette voie, je vous suggérerais d'écrire un outil de configuration que les utilisateurs finaux pourront utiliser au lieu de leur demander de modifier directement les fichiers.

ETA: D'après la réponse de Chris Dolan, il semblerait que YAML soit votre solution, car Catalyst l'utilise déjà (.yml est l'extension de facto pour les fichiers YAML).

<=> J'ai entendu dire que des personnes aveugles pouvaient avoir des difficultés avec cela

Answer 3

YAML est détestable pour la configuration - ce n'est pas convivial pour les programmeurs en partie parce que yaml dans pod est par définition cassé car ils dépendent tous les deux d'un espace différent. Ceci règle le principal problème de Config :: General. Dans le passé, j'ai écrit des fichiers de configuration assez compliqués avec C :: G, qui ne vous gênent pas pour ce qui est de la syntaxe, etc. Cependant, les conseils de Chris semblent déréglés.