Как ВЫ управляете модулями Perl при использовании менеджера пакетов? - PullRequest
31 голосов
/ 29 декабря 2008

A недавний вопрос здесь, на ТАК, заставил меня задуматься.

В большинстве дистрибутивов Linux, которые я пробовал, некоторые модули Perl были бы доступны через менеджер пакетов. Других, конечно, нет. В течение некоторого времени я использовал свой менеджер пакетов всякий раз, когда мне нужно было установить какой-либо модуль CPAN, чтобы узнать, доступен ли пакет или нет, и установить его, когда он был.

Очевидным преимуществом является то, что вы обновляете свои модули всякий раз, когда становится доступной новая версия пакета.

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

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

Как другие пользователи Perl в Linux справляются с этой проблемой? Вы просто игнорируете то, что могут предложить ваши менеджеры пакетов? Есть ли инструменты, которые делают apt (например) и cpan лучшими товарищами по команде? Или вы просто ничего не устанавливаете через оболочку cpan?

Ответы [ 10 ]

35 голосов
/ 29 декабря 2008

Для разработки я устанавливаю свой собственный Perl и оставляю систему Perl в покое. Если я хочу обновить системный Perl, я использую диспетчер системных пакетов. Для разработки Perl я использую инструмент cpan.

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

Очень легко установить отдельные Perls. Когда вы запустите Configure из исходного дистрибутива, он спросит вас, куда вы хотите установить все. Дайте ему любой путь, который вам нравится. Например, у меня установлено много Perls в / usr / local / perls , и все для каждой установки живет отдельно. Затем я создаю для них символические ссылки в / usr / local / bin (например, perl5.8.9, perl.5.10.0, perl5.10.0-thread). Когда я хочу конкретную версию, я просто использую ту, которая мне нужна:

$ perl5.10.0 program.pl

Определенный двоичный файл гарантирует, что программа выберет правильный путь поиска модуля и т. Д. (Это то же самое, что и модуль Config.pm для этого двоичного файла).

Вот скрипт, который я использую для создания символических ссылок. Он просматривает каталог bin, определяет версию Perl и создает ссылки типа cpan5.10.1 и так далее. Каждая программа уже знает правильный Perl для вызова:

#!perl

use 5.010;

use strict;
use warnings;

use File::Basename;
use File::Spec::Functions;

my $perls_directory = catfile(
    $ARGV[0] // '/usr/local/perls', 
    'perl*'
);
die "$perls_directory does not exist!\n" 
    unless -d dirname $perls_directory;

my $links_directory = $ARGV[1] // catfile( $ENV{HOME}, 'bin' ); #/
die "$links_directory does not exist!\n" unless -d $links_directory;

foreach my $directory ( glob( $perls_directory ) )
{
    say "Processing $directory...";

    unless( -e catfile( $directory, 'bin' ) )
    {
        say "\tNo bin/ directory. Skipping!";
        next;
    }

    my @perls = glob( catfile( $directory, qw( bin perl5* ) ) );    

    my( $perl_version ) = $perls[0] =~ m/(5\.\d+\.\d+)\z/;
    say "\tperl version is $perl_version";

    foreach my $bin ( glob( catfile( $directory, 'bin', '*' ) ) )
    {
        say "\tFound $bin";
        my $basename = basename( $bin );

        my $link_basename = do {
            if( $basename =~ m/5\.\d+\.\d+\z/) { $basename }
            else                               { "$basename$perl_version" }
        };

        my $link = catfile( $links_directory, $link_basename );
        next if -e $link;
        say "\t\tlinking $bin => $link";
        symlink $bin => $link or
            warn "\t\tCould not create symlink [$!]: $bin => $link!";
    }
}

Все устанавливается в нужном месте для этого конкретного Perl.

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

Я написал больше об этом в блоге Effective Perler:

12 голосов
/ 29 декабря 2008

Устанавливаем все через оболочку CPAN. Это игнорирует то, что должны предлагать менеджеры пакетов, но позволяет избежать головной боли, которую вы упоминаете при попытке работать с ними (запуск зависимостей, использование правильных версий).

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

8 голосов
/ 13 марта 2012

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

perlbrew switch $version
6 голосов
/ 30 декабря 2008

Я использую Debian для разработки и производства и полагаюсь на пакеты Perl Debian, поставляемые с дистрибутивом.

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

Конечно, этот метод не лишен недостатков, так как многие модули Perl Debian устарели (по крайней мере, в текущей стабильной версии Debian - etch), и имеют бэкпорт что-то вроде Catalyst , который имеет много зависимостей не практично.

Однако, опираясь на менеджер пакетов ОС, я сохраняю все его замечательные возможности, которые обеспечивают простоту обслуживания, особенно для развернутых серверов, поскольку вы точно знаете, какие пакеты установлены, и простой apt-get update;apt-get upgrade (из debian или из локального репозитория) обновляет все серверы до одного состояния, включая модули Perl.

6 голосов
/ 30 декабря 2008

Я делаю следующее на всех своих коробках:

  • Я собираю свой собственный Perl: я все еще использую 5.8. [89] в основном, у версии 5.10.0 есть регресс производительности, который меня сильно поражает, ожидая 5.10.1, чтобы повторить попытку;
  • Я использую (и настоятельно рекомендую) модуль local :: lib, чтобы сохранить каталог модуля для каждого проекта. В данный момент этот каталог rsync'едирован на все серверы, на которых установлен проект, но вместо этого я тестирую его с помощью git;
  • Я создаю модуль Task :: для каждого проекта, чтобы я мог установить все зависимости одной командой.
4 голосов
/ 15 февраля 2009

Я также использую оболочку cpan и local :: lib.

Вам не нужно задавать Task :: для каждого проекта. Просто используйте Module :: Install (мне нравится использовать Module :: Starter следующим образом:

$ module-starter --mi --module=Module::Name --author="Me" --email=me@cpan.org

и затем просто вставьте ваши зависимости в require 'module :: dependency'; в Makefile.PL. Наконец, когда наступает время установки, вы просто perl Makefile.PL (ответьте да), затем make installdeps

[править через 5 лет после того, как я дал этот ответ изначально]

В наши дни perlbrew и cpanm - это то, что нужно использовать. У local :: lib все еще есть сценарий использования, но комбинация perlbrew и cpanm решает расширенный набор этих случаев. Используйте local :: lib, когда вы не готовы скомпилировать свой собственный Perl.

0 голосов
/ 28 сентября 2017

Я недавно начал использовать Gentoo, и у Gentoo есть несколько очень важных преимуществ в этой области. Во-первых, g-cpan обычно способен устанавливать многие (хотя и не все) модули из CPAN в виде пакетов Gentoo, хотя обновление становится проблемой.

Обычно в Gentoo мой подход заключается в использовании g-cpan для создания файла ebuild, а затем установки из него, при необходимости подстройки. Преимущество в том, что обновление становится действительно простым. Затем я перемещаю файл из g-cpan / perl в dev-perl и помещаю его в оверлей, чтобы другие могли его использовать. Это позволяет мне быстро обрабатывать случаи, когда g-cpan этого не делает, и упаковка gentoo в любом случае очень проста /

0 голосов
/ 03 марта 2009

Я использую порты FreeBSD и упаковываю все зависимости CPAN в «метапорт» как своего рода локальный порт . FreeBSD имеет довольно большое количество CPAN-модулей, и их система сборки достаточно доступна , чтобы вы могли легко написать свой собственный порт, если он не существует - просто не забудьте отправить указанный порт так что он включается в дерево портов. Если у порта нет текущей версии на складе, вы всегда можете отредактировать Makefile для порта, чтобы он использовал новую версию, снова , не забудьте отправить изменение : -).

Наконец, я использую Tinderbox , чтобы построить весь беспорядок в виде бинарных пакетов, которые затем устанавливаю на все машины для производства и разработки.

Итог: как только вы преодолеете свою страсть к редактированию Makefile-ов, порты FreeBSD - отличный способ поддерживать ваше Perl-приложение и его зависимости.

0 голосов
/ 15 февраля 2009

Для производства:

При разработке выберите версию модуля perl, которая кажется подходящей для требований; если возможно, выберите поставленную версию целевой ОС (это делает большую часть следующего лишним), в противном случае выберите другую. Создайте для него файл спецификации RPM. Используйте виртуальную машину с чистой сборкой для создания RPM воспроизводимым способом (из файла спецификации / источника, зарегистрированного в соответствующей ветви).

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

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

Модули Perl НЕ обновляются никаким процессом, который не следует этой модели. Как и любое другое производственное программное обеспечение.

0 голосов
/ 29 декабря 2008

Я рекомендую использовать только cpan. Модули, включенные в дистрибутив Linux, предназначены только для охвата зависимостей пакетов. Когда вы устанавливаете Linux без доступа в Интернет только с компакт-дисков, он не может использовать cpan, поэтому некоторые модули включены в пакеты, но для разработчика Perl это плохо.

Кроме того, раньше у меня был cpan, настроенный для установки модулей у меня дома (.perl) без необходимости входа в систему root.

...