Если вы программер на perl, и читаете эту статью, то вы навярняка задавались вопросом — как устанавливать ваши скрипты, надо ли вообще делать дистрибутив, даже если вы не распространяете проект? Я несколько лет использовал свои скрипты, устанавливая их обычным копированием в отдельную папку и прописывая до нее путь, например через строки кода use lib qw(/path1 /path2) и т.п.. Такие скрипты работали, проблем не возникало, и я вообще не думал о дистрибутивах. Затем, понадобилось устанавливать несколько своих скриптов на несколько серваков, вот тогда я и сделал свой первый дистрибутив. Но до недавнего времени, я придерживался взгляда, что дистрибутив нужен только для публичного распространения, или когда вам надо использовать свои разработки на нескольких серваках. Но так ли это на практике?

Мое последняя точка зрения — если надо запускать проект, пусть и на одном сервере, надо все таки стремится сразу создавать дистрибутив. Ниже я рассмотрю несколько плюсов и минусов в сравнении с вариантом, когда вы используете простое копирование.

Но пока, давайте, определимся с термином «дистрибутив» для perl. Этим термином я буду называть упакованный пакет файлов (например tar.gz формата), который в своем составе имеет Makefile.PL — стартовый perl скрипт для формирования Makefile файла утилиты make. Также, «правильный» дистрибутив, помимо использования make, должен иметь две раздельные фазы работы. Первая — подготовка файлов, для их дальнейшей установки, внутри своей рабочей директории (исполняется не от ‘root‘, команда ‘make all‘, например). Вторая — установочная: подготовленные файлы копируются в нужные установочные директории (‘make install‘). Эта фаза либо исполняется от ‘root’, либо от какого либо пользователя, в его внутреннюю home директорию. Хочется заметить, что в отличии от компиляционных языков, типа C/C++, perl — язык интерпретатора, поэтому в большинстве случаев в компиляции не нуждается (кроме ‘XS’ модулей), а значит make мало что сможет сделать для нас, с первого взгляда. По этой причине, часто встает вопрос — а нужен ли дистрибутив?

Теперь давайте рассмотрим плюсы и минусы дистрибутива в сравнении с обычным копированием perl файлов.

+)

Дистрибутив — это прежде всего порядок в вашей голове по поводу файлов проектов — какие файлы рабочие, где библиотеки, где директории, созданные в процессе инсталлирования. Создавая дистрибутив, вы вынуждены наводить этот порядок. Но это окупится в дальнейшем.

-)

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

-)

Любые правки и их испытание на рабочем процессе — это всегда команда make install, заместо обычной правки PM или PL файла в месте, где он установлен руками. Но этот минус незначительный, так как make install обычно работает быстро — она отслеживает только те файлы, что вы изменили и инсталирует только их. Другими словами, после каждой правки исходников, для их тестирования, надо будет немного тратить больше времени.

+)

Если вы используете написание XS модулей (вставок C кода) в проекте — то без дистрибутива вам не обойтись — такие файлы требуют компиляции, и команда make просто необходима.

+)

Самый большой плюс перехода на дистрибутив — это возможность использования программ контроля версий. Я остановился на git (пробовал SVN — не понравился). Дело в том, что многие программы контроля версий не учитывают точные права Unix файлов — например, git хранит в репозитарии только статус файлов: исполняемый (‘x’) или нет — он не помнит user.group, в точности mode самого файла для (user, group, other) и даже не сохраняет дату модификации файла (то есть выставляет ее в «настоящее время»  между переключениями версий проекта, что на самом деле является плюсом, как нистранно — дата модификации служит ориентиром для make, что опять же плюс в использовании дистрибутива). То есть, если вы будете использовать git, вам надо будет иметь специальные свои программы, выставляющие права и/или копирующие файлы в другое месте после каждого переключения между версиями репозитария проекта (то есть без дистрибутива вы фактически создадите свой вариант дистрибутива без make, что будет являться «изобретением велосипеда»). А также надо учитывать то, что все программы контроля версий контролируют одну папку. А рабочие файлы проекта, как правило, живут не в одной папке, а раскиданы по нескольким. Поэтому программы контроля версий будут жить только с дистрибутивами.

+)

Написав грамотный make, можно улучшить порядок вашего проекта — make будет выставлять права, какие необходимы на рабочие директории, создавать их при необходимости и т.п.. Если вам придется запускать проект на другом нулёвом сервере — это будет минимум затрат по времени.

+)

Использование таких команд, как make distcheck, позволяет проверить, какие новые файлы вы добавили/создали, но не поместили их еще в MANIFEST (список файлов для дистрибутива, так сказать, список файлов «на экспорт»), поможет определиться, какие файлы надо убрать из дистрибутива (MANIFEST.SKIP). Все это — опять же порядок, который положительно скажется на вашем проекте (в MANIFEST не обязательно добавлять все файлы, некоторые можно иметь только в своей папке дистрибутива, а при подготовке «установочного» tar.gz архива они будут просто исключаться).

+)

Ваш проект, при создании дистрибутива, даст вам сразу такие преимущества: возможность легкого переноса вашего проекта на другие сервера без особых затрат, без проблем из него можно сделать open source проект и дать ему дальнейший импульс развития вне рамок вашей организации, или же сделать коммерческим проектом с легкой инсталяцией и т.п..

Вот вроде все плюсы и минусы, которые я обнаружил на основе своего опыта. Как видно, плюсов больше, чем минусов. Дополнительное время надо потратить только в самом начале проекта. Дальше — проще. В perl позаботились, чтобы облегчить жизнь разработчику — есть возможность отслеживать, какие новые файлы вы добавили в проект, но не добавили «на экспорт» в будущий дистрибут, или даже есть команды автоматического построения MANIFEST файла. Также, не надо руками создавать Makefile с длинным списком всех своих PL & PM файлов — «perl Makefile.PL» за вас найдет в нужных папках такие файлы и автоматом включит их в Makefile.

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