Как ВЫ управляете модулями Perl при использовании менеджера пакетов?
Недавний вопрос здесь о SO заставил меня задуматься.
В большинстве дистрибутивов Linux, которые я пробовал, некоторые модули Perl были бы доступны через менеджер пакетов. Других, конечно, нет. В течение некоторого времени я использовал свой менеджер пакетов всякий раз, когда мне нужно было установить какой-либо CPAN-модуль, чтобы узнать, доступен ли пакет или нет, и установить его, когда он был.
Очевидным преимуществом является то, что вы обновляете свои модули всякий раз, когда становится доступной новая версия пакета.
Однако у вас возникают проблемы, когда модуль недоступен в предварительно упакованном виде, и для этого модуля есть зависимости. Запускать менеджер пакетов каждый раз, когда оболочка cpan спрашивает, должна ли она следовать зависимости, может быть довольно утомительной.
Зачастую другим недостатком является версия предварительно упакованного модуля. Если вы используете Debian или Ubuntu, вы скоро обнаружите, что не сможете жить на переднем крае, как это делают многие авторы модулей CPAN.
Как другие Perl люди в Linux справляются с этой проблемой? Вы просто игнорируете то, что могут предложить ваши менеджеры пакетов? Есть ли инструменты, которые делают apt (например) и cpan лучшими товарищами по команде? Или вы просто ничего не устанавливаете через оболочку cpan?
10 ответов
Так как этот вопрос был первоначально задан, perlbrew был выпущен. Это делает установку пользовательских, самостоятельных установок perl тривиальной. И переключаться между этими версиями так же просто:
perlbrew switch $version
Для разработки я устанавливаю свой собственный 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:
Мы устанавливаем все через оболочку CPAN. Это игнорирует то, что должны предлагать менеджеры пакетов, но позволяет избежать головной боли, которую вы упоминаете при попытке работать с ними (запуск зависимостей, использование правильных версий).
Кроме того, это означает, что наши пакеты могут быть собраны программно (или вручную через оболочку) на любой платформе, где работает CPAN. Наличие зависимости от менеджера пакетов повлияет на вашу способность распространять ваше программное обеспечение на платформы, которые не используют / не поддерживают этот менеджер пакетов.
Я использую Debian для разработки и производства и полагаюсь на пакеты Perl Debian, которые поставляются с дистрибутивом.
В случаях, когда мне нужен модуль Perl, который недоступен в Debian, я обычно создаю свой собственный пакет Debian и устанавливаю его.
Конечно, этот метод не лишен недостатков, так как многие модули perl Debian устарели (по крайней мере, в текущей стабильной версии Debian - etch), и обратная передача чего-то вроде Catalyst, который имеет много зависимостей, нецелесообразна.
Однако, опираясь на менеджер пакетов ОС, я сохраняю все его замечательные возможности, которые обеспечивают простоту обслуживания, особенно для развернутых серверов, поскольку вы точно знаете, какие пакеты установлены, и простое apt-get update;apt-get upgrade (из Debian или из локального репозитория) обновляет все серверы до одного состояния, включая модули Perl.
Я делаю следующее на всех своих коробках:
- Я собираю свой собственный Perl: я все еще использую 5.8.[89] в основном, у версии 5.10.0 есть регресс производительности, который меня сильно поражает, ожидая, что 5.10.1 попытается снова;
- Я использую (и настоятельно рекомендую) модуль local::lib, чтобы сохранить каталог модуля для каждого проекта. Прямо сейчас этот каталог rsync'едирован для всех серверов, на которых установлен проект, но вместо этого я тестирую его с помощью git;
- Я создаю модуль Task:: для каждого проекта, так что я могу установить все зависимости одной командой.
Я также использую оболочку 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.
Я использую порты FreeBSD и оборачиваю все зависимости CPAN в "метапорт" как своего рода локальный порт. FreeBSD имеет достаточно большое количество модулей CPAN, и их система сборки достаточно доступна , чтобы вы могли легко написать свой собственный порт, если он не существует - просто не забудьте отправить указанный порт, чтобы он был включен в дерево портов. Если у порта нет текущей версии на складе, вы всегда можете отредактировать Makefile для порта, чтобы он использовал новую версию, опять же не забудьте отправить изменение:-).
Наконец, я использую Tinderbox для сборки всего беспорядка в виде бинарных пакетов, которые затем устанавливаю на все машины для производства и разработки.
Итог - Как только вы преодолеете свою страсть к редактированию Makefile-ов, порты FreeBSD станут отличным способом поддержки вашего perl-приложения и его зависимостей.
Я недавно начал использовать Gentoo, и у Gentoo есть несколько очень важных преимуществ в этой области. Во-первых, это g-cpan обычно способен устанавливать многие (хотя и не все) модули из CPAN как пакеты Gentoo, хотя обновление становится проблемой.
Обычно на Gentoo мой подход заключается в использовании g-cpan создать файл ebuild, затем установить с него, при необходимости подправив. Преимущество в том, что обновление становится действительно простым. Затем я перемещаю файл из g-cpan/perl в dev-perl и помещаю его в оверлей, чтобы другие могли его использовать. Это позволяет мне быстро обрабатывать случаи, когда g-cpan этого не делает, и упаковка Gentoo в любом случае является легкой задачей /
Я рекомендую использовать только cpan. Модули, включенные в дистрибутив Linux, предназначены только для покрытия зависимости пакетов. Когда вы устанавливаете Linux без доступа в Интернет только с компакт-дисков, он не может использовать cpan, поэтому некоторые модули включены в пакеты, но для разработчика Perl это плохо.
Также я использовал cpan, настроенный для установки модулей в моем доме (.perl) без необходимости входа в систему root.
Для производства:
В разработке выберите версию модуля perl, которая кажется подходящей для требований; если возможно, выберите поставленную версию целевой ОС (это делает большую часть следующего лишним), в противном случае выберите другую. Создайте для него файл спецификации RPM. Используйте виртуальную машину чистой сборки для создания RPM воспроизводимым способом (из specfile / source, зарегистрированного в соответствующей ветке).
Когда окончательная сборка может быть собрана (после слияния), сделайте ту же сборку из ветки выпуска, зафиксируйте сгенерированные RPM в репозиторий развертывания. Это будет использовано при окончательной проверке, а затем передано в производство путем копирования в производственный репозиторий.
Все производственные серверы используют один и тот же двоичный файл, который был полностью протестирован; они используют тот же файл спецификации и исходный код, что и разработчик.
Модули Perl НЕ обновляются никаким процессом, который не следует этой модели. Как и любое другое производственное программное обеспечение.