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

Question

Я в настоящее время нахожусь в проекте, который развивается, используя основу, разработанную другим отделом в качестве основы. В настоящее время мы внедряем стандарты качества (наконец-то, да!) В нашем отделе, но в настоящее время невозможно представить их в другом отделе. Как следствие, мы работаем против постоянно движущейся цели без стабильности API или стабильных выпусков, что по меньшей мере вызывает стресс.

Поскольку мы сначала пытаемся что-то исправить, мы хотели бы обезопасить себя от изменений в «восходящем» коде фреймворка a.k.a. Мы предполагали жесткие зависимости модуля:

1. Использование только определенных диапазонов версий каркасных модулей, определенных в коде.
2. Использование проверки модульного теста, чтобы убедиться, что все необходимые версии все еще доступны.
3. Каждое расширение диапазона версий, требующее рецензирования кода платформы.

Это план на данный момент. Теперь вопросы:

1. Это разумно? Если нет, то есть другие идеи?
2. Как реализовать это в perl? Используя use Module, мы можем определить только код самой младшей версии, с которым предполагается работать.

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

BEGIN {
    use foo;
    use bar;

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