31 июл. 2009 г., 19:46 от brian d foyNikolai Prokoschenko

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

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

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

Using only certain version ranges of framework modules, defined in code. Using a unit-test check to ensure that all necessary versions are still available. Every version range extension requiring peer-review of framework code.

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

Is it sensible? If not, any other ideas? How does one implement this in perl? Using use Module we can only define the lowest version code is supposed to work with.

Ответы на вопрос (0)

11 февр. 2015 г., 07:24 от sirfilip

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

31 июл. 2009 г., 19:11 от jimtut

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

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

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

31 июл. 2009 г., 19:27 от wazoox

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

BEGIN {
    use foo;
    use bar;

    die "Ghaaaa" if $foo::VERSION < 2.1;
    die "Aaaargh" if $foo::VERSION > 3.12;
}
31 июл. 2009 г., 19:26 от Chas. Owens

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

01 авг. 2009 г., 10:49 от tsee

Кто-то указалPAR уже. Позвольте мне упомянутьPAR :: Repository и это сопутствующий модульPAR :: Repository :: Client. They implement a client/server infrastructure that can automatically load any dependencies that aren't found locally (or that can even prefer the server's packages). As an administrator, you can simply add or remove packages to or from your repository. The actual serving of packages is done with utterly normal servers: Any http(s) server or simply file:// will do. Other protocols should be rather straightforward to implement.

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

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

31 июл. 2009 г., 19:43 от brian d foy

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

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

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

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

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

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

31 июл. 2009 г., 19:15 от Sinan Ünür

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

ВАШ ОТВЕТ НА ВОПРОС