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

Но пока, давайте, определимся с термином «дистрибутив» для 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 дистрибутивы. Для начинающих это может показаться сложно, так как надо читать много документации, прежде чем понять это. Я попробую рассказать об этом, опуская все лишнее.

И вот, наконец, сегодня я прочел грамотную доку, а также в другом месте нашел объяснение моим проблемам. Оказывается, в sed есть очень мелкие, но важные отличия, поняв которые, вы сможете писать sed команды легко.

Итак, оказывается, по историческим причинам, чтобы не нарушать работу старых sed команд, в sed группировка (‘(‘, ‘)’) и некоторые другие спец. символы (‘+’ , ‘?’) были заменены на символы со слешем. Вот эти отличия:

Самое главное, на чем я спотыкался всегда – я никак не мог додуматься, что ‘\’ должен ставиться перед ‘(‘, или перед ‘?’ и ‘+’ символами, например. Я видел иногда эти слеши в примерах, но я думал, что эти слеши относились к shell, но оказалось, что это тонкость sed-а.

P.S. Возникает вопрос, а как же тогда заменять сами символы: «?+{}()» в sed? А оказывается, их просто не надо ескейпить символом ‘\’. Получается как бы наоборот – эти символы сами по себе не ескейпяться, а когда нужно их специальное назначение, то перед ними ставим ‘\’. Типа все с ног на голову, если сравнивать с perl.