Как вы используете модули Perl при использовании диспетчера пакетов?

Ответ 1

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

perlbrew switch $version

Ответ 2

Для разработки, я устанавливаю свой собственный 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-threaded). Когда я хочу определенную версию, я просто использую тот, который я хочу:

$ perl5.10.0 program.pl

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

Здесь script Я использую для создания символических ссылок. Он выглядит в каталоге 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:

• Создавать ссылки на инструменты для каждой версии.
• Управление модулями Perl с помощью Git.

Ответ 3

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

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

Ответ 4

Во всех моих полях я делаю следующее:

• Я скомпилирую свой собственный perl: я все еще использую 5.8. [89] в основном, у акций 5.10.0 есть регрессия производительности, которая очень сильно меня поражает, ожидая, что 5.10.1 повторит попытку;
• Я использую (и настоятельно рекомендую) локальный модуль:: lib для хранения каталога модулей для каждого проекта. Прямо сейчас этот каталог rsync'ed для всех серверов, на которых установлен проект, но я тестирую вместо этого git;
• Я создаю модуль Task:: для каждого проекта, поэтому я могу установить все зависимости с помощью одной команды.

Ответ 5

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

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

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

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

Ответ 6

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

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

$ module-starter --mi --module=Module::Name --author="Me" [email protected]

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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

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

Ответ 9

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

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

Нижняя строка. Как только вы преодолеете фобию редактирования Make файлов, FreeBSD-порты - отличный способ поддерживать ваше приложение perl и его зависимости.

Ответ 10

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

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