Подтвердить что ты не робот

Как найти зависимости модуля от моего Perl script?

Я хочу, чтобы другой разработчик запускал Perl script, который я написал. script использует много модулей CPAN, которые должны быть установлены до запуска script. Можно ли сделать script (или двоичный код perl) сбросить список всех отсутствующих модулей? Perl печатает имена недостающих модулей при попытке запустить script, но это подробный и не перечисляет сразу все недостающие модули. Id нравится делать что-то вроде:

$ cpan -i `said-script --list-deps`

Или даже:

$ list-deps said-script > required-modules # on my machine
$ cpan -i `cat required-modules` # on his machine

Есть ли простой способ сделать это? Это не шоу-стоппер, но я хотел бы облегчить жизнь другим разработчикам. (Необходимые модули посыпаны несколькими файлами, поэтому мне нелегко составить список вручную, не пропуская ничего. Я знаю о PAR, но это кажется слишком сложным для того, что я хочу.)

Обновление: Спасибо, Манни, что будет. Я не знал о %INC, я знал только о @INC. Я решил что-то вроде этого:

print join("\n", map { s|/|::|g; s|\.pm$||; $_ } keys %INC);

Что печатает:

Moose::Meta::TypeConstraint::Registry
Moose::Meta::Role::Application::ToClass
Class::C3
List::Util
Imager::Color
…

Похоже, это сработает.

4b9b3361

ОТВЕТЫ

Ответ 1

Вы можете сбросить %INC в конце вашего script. Он будет содержать все используемые и необходимые модули. Но, конечно, это будет полезно, только если вы не требуете модулей условно (требуется Foo, если $bar).

Ответ 2

Отметьте Module:: ScanDeps и утилиту scandeps.pl, которая поставляется вместе с ней. Он может выполнять статический (и рекурсивный) анализ вашего кода для зависимостей, а также дамп% INC либо после компиляции, либо запуска программы.

Обратите внимание, что сканирование статического источника всегда ошибочно на стороне включения слишком большого количества зависимостей. (Это сканер зависимостей, используемый PAR и нацеленный на то, чтобы быть простым для конечного пользователя.)

Наконец, вы можете выбрать распространение script в качестве дистрибутива CPAN. Это звучит намного сложнее, чем есть на самом деле. Вы можете использовать что-то вроде Module:: Starter, чтобы настроить базовый скелет ориентированного дистрибутива App:: YourScript. Поместите ваш script в подкаталог bin/и отредактируйте Makefile.PL, чтобы ссылаться на все ваши прямые зависимости. Затем для распределения вы делаете:

  • perl Makefile.PL
  • сделать
  • сделать dist

Последний шаг создает приятный App-YourScript-VERSION.tar.gz Теперь, когда клиент хочет установить все зависимости, он делает следующее:

  • Правильно настройте клиент CPAN. Просто запустите его и ответьте на вопросы. Но вы все равно этого требуете.
  • "tar -xz App-YourScript-VERSION.tar.gz & cd App-YourScript-VERSION"
  • Запустите "cpan".

Клиент CPAN теперь будет автоматически устанавливать все прямые зависимости и зависимости этих распределений. В зависимости от того, как вы его настроите, он будет автоматически или автоматически следовать за предпосылками автоматически или запросить с помощью y/n каждый раз.

В качестве примера вы можете проверить несколько дистрибутивов App:: * в CPAN. Я бы подумал, что App:: Ack - хороший пример. Возможно, это один из дистрибутивов App:: * из моего каталога CPAN (SMUELLER).

Ответ 3

Для быстрого и нечистого, нечастого использования, %INC - лучший способ. Если вам нужно сделать это с помощью непрерывного тестирования интеграции или чего-то более надежного, есть и другие инструменты.

Штеффен уже упомянул модуль:: ScanDeps.

Код в Test:: Prereq делает это, но у него есть дополнительный уровень, который гарантирует, что ваши списки Makefile.PL или Build.PL их как зависимость. Если вы создаете сценарии которые выглядят как обычный дистрибутив Perl, это позволяет легко проверить наличие новых зависимостей; просто запустите тестовый набор снова.

Кроме того, вы можете использовать такой инструмент, как Module:: Extract:: Use, который анализирует статический код, который ищет использование и требуют операторов (хотя они не найдут их в строковых оценках). Это доставит вам только те модули, которые вы сказали при загрузке script. Кроме того, как только вы узнаете, какие модули вы загрузили, вы можете комбинировать это с инструментом David Cantrell CPANdeps, который уже создал дерево зависимостей для большинства CPAN модули.

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

sub foo
    {
    require Bar; # don't load until we need to use it
    ....
    }

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

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

Ответ 4

Другим инструментом в этой области, который используется Dist:: Zilla и его плагином AutoPrereqs, является Perl:: PrereqScanner. Он устанавливает программу scan-perl-prereqs, которая будет использовать PPI и несколько плагинов для поиска большинства видов объявлений prereq, используя минимальные версии, которые вы определяете. В общем, я предлагаю это при сканировании %INC, что может привести к фиктивным требованиям и игнорировать версии.

Ответ 5

Сегодня я разрабатываю свои приложения для Perl как CPAN-подобные дистрибутивы, используя Dist::Zilla, который может заботиться о зависимостях через плагин AutoPrereq. Еще один интересный фрагмент кода в этой области carton.