Какой самый лучший модуль Perl для иерархической и наследуемой конфигурации? - PullRequest
Новая
       24

Какой самый лучший модуль Perl для иерархической и наследуемой конфигурации?

5 голосов
/ 15 марта 2009

Если у меня есть проект с нуля, какой модуль конфигурации на основе Perl лучше всего использовать?

Будет приложение Catalyst и несколько сценариев командной строки. Они должны иметь одинаковую конфигурацию.

Некоторые функции, я думаю, что я хочу ...

Иерархические конфигурации для чистого поддержания различных параметров разработки и оперативных параметров.

Я бы хотел один раз определить «глобальные» конфигурации (например, results_per_page => 20), чтобы они были унаследованы, но переопределены в моих конфигурациях 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

Когда я развертываю проект на новом сервере или ветвлю / разветвляю / копирую его где-то в новом месте (например, в новый экземпляр разработки), я хочу (только один раз) указать, какой конфигурационный набор / файл использовать, а затем все последующие обновления выполняются автоматически.

Я бы предположил, что это может быть достигнуто с помощью символической ссылки: 

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

Тогда в будущем 

git pull # or any equiv vcs

Мне бы также хотелось что-то похожее на FindBin, чтобы мои конфиги могли использовать либо абсолютные пути, либо относительно текущего развертывания. Учитывая 

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

где / home / me / development / project / etc / config содержит: 

tmpl_dir: templates/

когда мой perl-код ищет конфигурацию tmpl_dir, он получает: 

/home/me/development/project/templates/

Но в режиме реального времени: 

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

Тот же код волшебным образом вернет 

/var/www/project/templates/

Необходимо учитывать абсолютные значения в конфигурации, так что: 

apache_config: /etc/apache2/httpd.conf

вернет "/etc/apache2/httpd.conf" во всех случаях.

Вместо подхода, основанного на стиле FindBin, альтернативой может быть разрешение определения значений конфигурации в терминах других значений конфигурации? 

tmpl_dir: $base_dir/templates

Я бы тоже хотел пони;)

Ответы [ 3 ]

9 голосов
/ 15 марта 2009

Catalyst :: Plugin :: ConfigLoader поддерживает несколько перезаписывающих файлов конфигурации. Если ваше приложение Catalyst называется MyApp, то оно имеет три уровня переопределения: 1) MyApp.pm может иметь директиву __PACKAGE__->config(...), 2) затем оно ищет MyApp.yml в основном каталоге приложения, 3) это выглядит для MyApp_local.yml. Каждый уровень может переопределять настройки на каждом другом уровне.

В приложении Catalyst, которое я создал, я поместил все свои неизменные настройки в MyApp.pm, мои настройки отладки в MyApp.yml и мои производственные настройки в MyApp_<servertype>.yml, а затем вставил символическую ссылку MyApp_local.yml, чтобы указать MyApp_<servertype>.yml на каждом развернутом сервере (все они были немного разные ...).

Таким образом, все мои настройки были в SVN, и мне просто понадобился один шаг ln -s для ручной настройки сервера.

6 голосов
/ 15 марта 2009

Perl Best Practices предостерегает против именно того, что вы хотите. В нем говорится, что файлы конфигурации должны быть простыми и избегать тех функций барокко, которые вы желаете. Далее рекомендуется три модуля (ни один из которых не является Core Perl): Config :: General , Config :: Std и Config :: Tiny .

Общее рациональное обоснование этого заключается в том, что редактирование файлов конфигурации обычно выполняется непрограммистами, и чем сложнее вы создаете свои файлы конфигурации, тем больше вероятность, что они их испортят.

Все это говорит, вы могли бы взглянуть на YAML . Он обеспечивает полнофункциональный, читаемый человеком *, формат сериализации. Я считаю, что в Perl рекомендуется парсер YAML :: XS . Если вы пойдете по этому пути, я бы предложил написать инструмент конфигурации для использования конечными пользователями вместо того, чтобы они редактировали файлы напрямую.

ETA: Судя по ответу Криса Долана, звучит так, будто YAML - это то, что вам нужно, поскольку Catalyst уже использует его (.yml - это де-факто расширение для файлов YAML).

* Я слышал жалобы на то, что у слепых могут возникнуть проблемы с этим

2 голосов
/ 15 марта 2009

YAML ненавистен для конфигурации - он не дружественен к программисту, отчасти потому, что yaml в pod по определению нарушен, поскольку они оба по-разному зависят от пробелов Это решает основную проблему с Config :: General. В прошлом я написал несколько довольно сложных конфигурационных файлов для C :: G, и это действительно мешает вам с точки зрения требований к синтаксису и т. Д. Кроме этого, совет Криса, кажется, стоит денег.

...