Как я могу управлять зависимостями модуля Perl?

Это очень разумный план, и я реализую его через частный репозиторий, похожий на CPAN, который я называю «DPAN». Вы выбираете нужные дистрибутивы и версии из реального CPAN (или BackPAN) и создаете из него свой собственный репозиторий. Ваши CPAN-клиенты указывают только на этот репозиторий, фактически замораживая версии именно так, как вам нужно. Вы только обновить, когда вы хотите.

Кроме того, DPAN позволяет вам легко добавлять не только свой собственный локальный частный код, но и модифицировать сторонние пакеты для устранения проблем с их установкой и т. д. У меня есть полное обоснование этой идеи в летнем выпуске журнала Обзор Perl. Вы также можете посмотреть мои слайды из моего доклада Создание собственного CPAN на YAPC. ::Россия.

Если вам интересно такое решение, ознакомьтесь с моим MyCPAN::App::DPAN модуль. Он берет каталог дистрибутивов и делает все остальное за вас. Вы указываете на него своему CPAN-клиенту (и гарантируете, что он не будет подключаться к Интернету), и все.

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

Следующий большой шаг в моей работе с DPAN — взять существующую установку Perl с любыми модулями, которые вы могли установить, и создать репозиторий, который даст вам это состояние установки. У меня есть все основные части, необходимые для работы, но я был немного занят, чтобы заставить пару клиентов работать с первыми частями.

Если вы хотите узнать больше об этом материале, просто дайте мне знать. :)

Взгляните на PAR. Он позволяет объединить набор зависимостей в один файл. Вы можете взять модули, которые они выпускают, добавить их в PAR-файл и обновить PAR-файл только тогда, когда захотите принять их изменения.

Хотя я надеюсь, что CPAN более стабилен, чем модули, на которые вы полагаетесь, позвольте мне задать аналогичный вопрос: как вы защитите себя от неожиданных изменений в модуле CPAN?

Один ответ: вы загрузите модуль и регрессируете свой код против него в тестовой среде.

Можно ли использовать здесь то же самое? Вы должны указать на «живые» копии их модулей, или вы могли бы указать на свои собственные копии?

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

Ну, я думаю, что Carton — это то, что вы ищу (сборщик для perl). В сочетании с plenv я считаю, что это поможет.

Кто-то уже указал на PAR. Позвольте мне упомянуть PAR::Repository и его сопутствующий модуль PAR::Repository::Client. Они реализуют инфраструктуру клиент/сервер, которая может автоматически загружать любые зависимости, которые не найдены локально (или которые могут даже предпочесть пакеты сервера). Как администратор, вы можете просто добавлять или удалять пакеты в свой репозиторий или из него. Фактическая доставка пакетов осуществляется с помощью совершенно обычных серверов: подойдет любой сервер http(s) или просто file://. Другие протоколы должны быть довольно простыми в реализации.

Он имеет вышеупомянутый волшебный механизм автозагрузки, установку пакетов и автоматическое обновление пакетов. Помимо документации модуля, вы можете ознакомиться с презентацией PAR с YAPC::Europe 2008, который до некоторой степени покрывает это.

Я должен признать, что автоматическое обновление — достаточно продвинутая технология, которая может съесть ребенка или двух, если у нее закончатся котята, которых можно грызть.

Если вы хотите проверить версию внешних модулей, вы можете (если они хотя бы правильно сообщают о своей $VERSION) использовать что-то вроде этого:

BEGIN {
    use foo;
    use bar;

    die "Ghaaaa" if $foo::VERSION < 2.1;
    die "Aaaargh" if $foo::VERSION > 3.12;
}