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

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

Кроме того, DPAN позволяет вам легко добавлять не только ваш собственный локальный частный код, но и изменять сторонние пакеты для устранения проблем с их установками и т. Д. У меня есть полное обоснование для эта идея была изложена в летнем выпуске журнала The Perl Review летом 2009 года. Вы также можете увидеть мои слайды из моего выступления Создание собственного CPAN на YAPC :: Russia.

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

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

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

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

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

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

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

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

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

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

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

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

BEGIN {
    use foo;
    use bar;

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