Jaki jest najlepszy moduł Perla do hierarchicznej i dziedzicznej konfiguracji?

Question

Jeśli mam projekt typu greenfield, jaki jest najlepszy moduł konfiguracyjny oparty na Perl?

Pojawi się aplikacja Catalyst i niektóre skrypty wiersza poleceń. Powinny mieć tę samą konfigurację.

Niektóre funkcje myślę, że chcę ...

hierarchiczne konfiguracje do czysto utrzymać inny rozwój i ustawień na żywo.

Chciałbym raz zdefiniować konfiguracje "globalne" (np. Results_per_page => 20), mieć te odziedziczone, ale można je zastąpić moimi konfiguracjami 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 

Kiedy wdrożyć projekt na nowy serwer, lub oddział/widelec/skopiuj go gdzieś nowy (na przykład nowa instancja rozwój), chcę (jeden jedyny raz) zestaw, który zestaw konfiguracyjny/plik używać, a następnie wszystkie przyszłe aktualizacje są automatyczne.

bym przewidzieć można to osiągnąć z dowiązania symbolicznego:

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

Wtedy w przyszłym

git pull # or any equiv vcs 

Chciałbym również, że jak coś podobnego do FindBin, więc możliwe, że moje configs albo użyj ścieżek bezwzględnych, albo względem bieżącego wdrożenia. Biorąc

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

gdzie/home/ja/rozwój/projekt/etc/config zawiera:

tmpl_dir: templates/ 

kiedy mój kod Perl wygląda konfigurację tmpl_dir będzie to dostać:

/home/me/development/project/templates/ 

Ale w wersji na żywo:

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

Ten sam kod będzie magicznie powrócić

/var/www/project/templates/ 

wartościach bezwzględnych w config powinien być zaszczycony, że tak:

apache_config: /etc/apache2/httpd.conf 

wróci „/etc/apache2/httpd.conf” we wszystkich przypadkach.

Zamiast podejścia opartego na FindBin, alternatywą może być zdefiniowanie wartości konfiguracyjnych w kontekście innych wartości konfiguracyjnych?

tmpl_dir: $base_dir/templates 

że również jak pony I;)

Answer 1

Catalyst::Plugin::ConfigLoader obsługuje wiele nadrzędne pliki konfiguracyjne. Jeśli twoja aplikacja Catalyst nazywa się MyApp, ma trzy poziomy przesłonięcia: 1) MyApp.pm może mieć dyrektywę __PACKAGE__->config(...), 2) następnie szuka MyApp.yml w głównym katalogu aplikacji, 3) szuka MyApp_local.yml. Każdy poziom może przesłonić ustawienia na każdym innym poziomie.

W aplikacji Catalyst I zbudowany, kładę wszystkich moich niezmiennych ustawień w MyApp.pm, moje ustawienia debugowania w MyApp.yml i moje ustawienia produkcyjne w MyApp_<servertype>.yml a następnie dowiązane MyApp_local.yml wskazać na MyApp_<servertype>.yml każdego wdrożonego serwera (byli wszystko trochę inaczej ...).

W ten sposób cała moja konfiguracja była w SVN i potrzebowałem tylko jednego kroku ln -s, aby ręcznie skonfigurować serwer.

Answer 2

Perl Best Practices ostrzega przed dokładnie to, co chcesz. Stwierdza, że ​​pliki konfiguracyjne powinny być proste i unikać tego, jakiego rodzaju barokowych funkcji pragniesz. Następnie poleca trzy moduły (z których żaden nie jest Core Perl): Config::General, Config::Std i Config::Tiny.

Ogólnie rzecz biorąc, racjonalne jest to, że edytowanie plików konfiguracyjnych jest wykonywane przez programistów, a im bardziej skomplikowane pliki konfiguracyjne, tym większe prawdopodobieństwo, że je zepsują.

Wszystko to powiedziawszy, możesz rzucić okiem na YAML. Zapewnia w pełni funkcjonalny, czytelny dla człowieka format serializacji *. Uważam, że obecnie polecany parser w Perlu to YAML::XS. Jeśli wybierzesz tę trasę, proponuję napisanie narzędzia konfiguracyjnego, z którego będą korzystać użytkownicy końcowi, zamiast bezpośredniego edytowania plików.

ETA: Na podstawie odpowiedzi Chrisa Dolana brzmi to tak, jakby YAML był dla ciebie drogą, odkąd Catalyst już go używa (.yml jest de facto rozszerzeniem dla plików YAML).

* Słyszałem skargi, że osoby niewidome mogą mieć trudności z nim

Answer 3

YAML jest nienawistny dla config - to nie non-programista przyjazny częściowo dlatego yaml w kapsule jest z definicji uszkodzony jak oboje white-space zależne na różne sposoby. This rozwiązuje główny problem związany z Config :: General. Napisałem już dość skomplikowane pliki konfiguracyjne z C :: G w przeszłości i naprawdę trzymałem się z daleka pod względem wymagań składniowych itp. Poza tym, rada Chrisa wydaje się dotyczyć pieniędzy.