Поделитесь опытом разбивки перлового приложения на модули

Это тема когда пробегала в moscow.pm , а так может посмотреть как это реализовано в http://search.cpan.org/~jv/Getopt-Long-2.38/lib/Getopt/Long.pm , catalyst, mojolicuos .
В основном логику пихают в подпапку lib тесты в t(это как бы негласный формат)

Зависит от специфики проекта. Скрипты с расширением *.pl размещаю в директории ./scripts, а тестовые скрипты (расширение *.t) в директории ./t.

Тестовые скрипты запускаю как `prove -s -j8 ./t` или просто `prove ./t` если .proverc.

Либы проекта храню в ./lib, а подключаю в скриптах (те что в скриптс) при помощи либы lib::abs:

#!/usr/bin/perl

use lib::abs qw( ../lib );

Деплой у меня очень простой - чекаут из системы контроля версий, прогон тестов (в том числе зависимостей от CPAN), правка конфигов.

Обычно тестовый набор включает файл «00_installed_modules.t», проверяющий наличие в системе перловых модулей (свои проекты как code reuse, так и сторонние - обычно CPAN) нужных версий.

Также юзаю «01_script_compiles.t», стартующий скрипты из ./scripts и проверяющий насколько эти скрипты готовы к работе (компилятся). Для проверки вызываю каждый скрипт с параметром -c (`perl -c ./scripts/tratata.pl`). Вот тут тонкости - чтобы диагностировать проблемы, желательно импортировать модули не через require, а через use, чтобы поймать баги еще на этапе компиляции. Исключением может быть порождающий паттерн, такой как фабрика.

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

/etc/environment (или другие rc файлы):

PERL5LIB="/path/to/perl/site:/some/other/site"

Универсальное правило PERL5LIB. Другие варианты вроде use lib, shift/unshift @INC усложняют жизнь ментейнерам/разработчикам. Также на модули можно бить и в рамках одного файла:

package My::Module;

.....

package main;

use My::Module;

my $obj = new My::Module
  option1 => "some_var",
  option2 => "other_var";