Можно ли распаковать зависимости Perl в локальное дерево (например, Ruby on Rails)? - PullRequest
1 голос
/ 17 февраля 2010

Я интегрирую с некоторым существующим "устаревшим" кодом Perl для моего текущего проекта. Я загружаю некоторые библиотеки через CPAN для использования в скрипте Perl, но я бы хотел, чтобы другие разработчики / пользователи не устанавливали эти библиотеки вручную. Взяв страницу из моего фона Ruby / Rails, я подумал, что можно было бы «распаковать» зависимости в локальный каталог, который находится под контролем версий, а затем загрузить библиотеки оттуда. Преимущества заключаются в том, что (1) никто не должен устанавливать определенные пакеты вручную, и (2) вы знаете, что у всех одна и та же версия, и они могут легко обновить эту версию.

Я попробовал простой подход и просто переместил установочные файлы в ./vendor/Perl/Pod/, ./vendor/Perl/DBD/, ./vendor/Perl/Win32/ и т. Д. И скорректировал @INC соответственно. Это работало нормально для некоторых библиотек, но не для других. Я предполагаю, что скомпилированные библиотеки вызывают проблемы, а также зависимости.

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

Я не очень знаком с Perl, поэтому заранее прошу прощения за свое невежество.

Ответы [ 2 ]

4 голосов
/ 17 февраля 2010

Я бы использовал для этого local :: lib . Он устанавливает переменные среды для вас, затем вы можете установить модули CPAN как обычно и установить их в локальном каталоге.

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

Редактировать

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

Я все еще предлагаю использовать local :: lib. Объедините его с make-файлом для вашего проекта, который установит необходимые вам зависимости. (Предполагая, что пользователи Windows используют Strawberry Perl)

2 голосов
/ 17 февраля 2010

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

К счастью, есть много способов обойти эту проблему. Вы могли бы:

  • используйте PAR для управления пакетами модулей.
  • используйте lib lib , чтобы добавить дополнительные каталоги в список каталогов для поиска.
  • установить переменную окружения PERL5LIB , чтобы изменить поведение поиска в каталоге.
  • вызывает perl с помощью опции -I , чтобы добавить каталоги в путь поиска модуля.
...