Как распространять нативные Perl-скрипты без использования дополнительных модулей?

Question

Как кто-то может распространять собственные (не "скомпилированные / perl2exe / ...") сценарии Perl, не заставляя пользователей знать о пользовательских (не CPAN) модулях, которые нужны сценариям для запуска?

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

Я иногда соглашался просто скопировать модуль в реальный скрипт, но я бы предпочел более чистое решение.

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

Answer 1

Правильный способ - сказать им: «Не делай этого!» Я надеюсь, что они не будут перемещать exe-файл и программа продолжит работать. Это ничем не отличается.

Тем не менее, есть несколько альтернатив. Одним из них является замена сценария оболочкой (например, pl2bat), которая знает полный путь к реальному сценарию. Другой способ - использовать PAR , но для этого потребуется установить PAR и / или parl (из PAR :: Packer).

Answer 2

Если сценарию, который вы подготовили для клиента, нужны «пользовательские» модули, просто упакуйте свои модули так, как если бы вы пытались загрузить их в cpan. Затем передайте пакет клиенту, и он сможет использовать утилиту cpan для установки скрипта и модулей.

Answer 3

В качестве варианта «соберите все свои модули в одном месте и сделайте так, чтобы ваши приложения знали об этом», который будет работать даже на нескольких компьютерах и в сетях, возможно, вам следует проверить PAR :: Repository и соответственно PAR :: Repository :: Client . Вы бы просто предоставили один исполняемый файл двоичного клиента, который подключается к хранилищу (через файловую систему или https) и выполняет любое из произвольного числа программ (используя произвольный набор модулей), предоставляемых хранилищем, которое запрашивает пользователь.

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

Answer 4

Распространите установщик вместе со сценарием. Установщик должен быть запущен с правами суперпользователя, и он поместит пользовательские модули в стандартное расположение системы (/ usr / local / lib / perl5 / site_perl или что-то еще).

Я не пробовал это, но Module :: Install выглядит полезным в этом отношении. Это описывается как:

Автономный, расширяемый установщик Perl-модуля

Answer 5

Я на самом деле придумала собственное решение, и мне любопытно, какой это будет прием.

Я написал скрипт, который читает Perl-скрипт и ищет операторы «use / require». Найдя их, он проверяет, является ли модуль частью стандартной библиотеки (ищет путь к модулю /perl5/\d+.\d+[\d.]+/), а затем переписывает строку use / require двумя различными способами в зависимости от использование.

Если требуется найдено:

{
    ... inline the entire module here...
}

Если , использовать найдено:

BEGIN {
    ... inline the entire module here...
}

Если использует , имеет импорт , сразу же следуйте приведенным выше инструкциям:

BEGIN { import Module ...imports seen... }

Я понимаю, что не не работает с модулями, которые используют XS, но я был в порядке с этим. В основном мне нужно поддерживать только чистые модули Perl.

Answer 6

Было бы здорово, если бы вы могли просто использовать пакет в стиле NeXTSTEP . Поскольку вы, вероятно, не разрабатываете платформу, использующую пакеты, вам придется с этим справляться.

Поместите все файлы поддержки в известное место и укажите свой исполняемый файл на эти файлы для доступа к настройкам и библиотекам. Самый простой способ сделать это с помощью простого установщика.

Например, с приложением foo поместите все необходимые файлы в /opt/xlyd_apps/foo, библиотеки в /opt/xlyd_apps/foo/lib, конфигурацию в /opt/xlyd_apps/foo/etc и т. Д. Поместите исполняемый файл в /opt/xlyd_apps/foo/bin.

Важно убедиться, что исполняемый файл знает, что ищет в /opt/xlyd_apps/foo все свои плюсы, поэтому, если клиент / клиент переместит скрипт foo в новое место, установка все равно будет работать.

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