Skaji cpm не хочешь?

А cpm умеет в детерминированную установку? Опять напоролся на установку более свежей версии транзитивной зависимости, чем мне нужно. И вообще, какие-то пакетники для perl поддерживают что-то вроде lock-файлов?

carton?

Он умеет? Мне казалось, что он использует cpanm, который не умеет детерминированно ставить.

Может я не правильно понял этот термин. Думал, что хочется поставить что-то типа: package >=7.10 < 9.5

Имеется в виду, хочется поставить: requires 'Dep', '== X.Y'; requires 'Foo', '== K.L'; requires 'Bar', '== A.B'; Но какая-то из этих сволочей обновляет Dep до ненужной версии.

Dep вниз переместить. ;) Это я так, предположил.

В cpanm порядок не влияет (точнее, он недетерминистичный - там внутри видимо где-то perl hash используется)

Да, у carton влиять может. Попробуйте. Я так в некоторых местах его использовал, где надо было некоторые пакеты с определенными только версиями ставить.

Хм, а если какая-то из этих сволочей сломается от старой Dep?

Может через Carmel как раз всё можно сделать. Он всё через роллаут в local положит нужное. Ну и в тарболл всё сможет собрать, все модули.

Да, проверил ещё раз. Каждый раз ставит модули в разном порядке, пару раз может повезти, а потом: Can't merge requirements for Dep: 'K.L' and '== X.Y' at .../Menlo/Dependency.pm line 53. А потом: ! Installing the dependencies failed: Installed version (X.Y) of Dep is not in range 'K.L' ! Bailing out the installation for XYZ-H.J. Причём в конце, типа успех: 143 distributions installed Complete! Modules were installed into .. Причём модуль XYZ, на который ругалось, вроде поставилось. В общем, гремлины какие-то занимаются установкой...

Тогда Carmel :)

Я в это полез, т.к. у меня кое что в моём легаси сломалось от более новой Dep. Хорошо, что юнит-тест был.

А ещё, carton не тестит при установке модулей и это не отключается... Что-то сомневаюсь я, что оно работает...

Ну как сказать, он пишет кучу варнингов, но да, обновляет до не тех версий, которые ты хочешь

Он и не должен. Предполагается что ты этот набор модулей уже проверил

С помощью какого инструмента?

Cpanm, cpm, руками. Собрал окружение, проверил, прописал версии в картонфайл

В каком смысле собрал окружение? Вот, скажем, берём чистый докер-образ. Ставим туда нужный perl, cpanm, либы (openssl), carton/carmel. И как проверить, что указанный набор perl-модулей, вообще, собирается с теми инклюдами, которые есть в системе?

Ну собираешь картоном окружение, запускаешь юнит тесты. Прошли- значит всё хорошо, не прошли - всё плохо :)

carmel тоже странная штука оказалась. Это какой-то гибрид plenv + carton, т.е. он одновременно умеет управлять окружениями, как plenv/virtualenv/rbenv, так и зависимостями. Причём последние ставит не в ./local, а куда-то к себе в .carmel Но мой набор зависимостей он не смог собрать, причём непонятно, где фигня (и, что самое интересное, не даёт даже сделать carmel tree - мол, сначала поставь, а потом покажу)

Юнит тесты чего? carton не даёт прогонять юнит-тесты пакетов.

carmel ставит всё в ~/.carmel, а после carmel rollout выкатывает всё по нужным версиям из ~/.carmel в yourpoject/local

Да, и я, кажется, понял почему. Все эти тулы - cpm, carton, carmel - под капотом используют те же классы, что и cpanm (Menlo). И все они для установки, по сути, пользуются внешним инструментом. Хотя, по идее, логично было бы зарезолвить и скачать верхний уровень зависимостей, посмотреть зависимости этих зависимостей, зарезолвить их (с учётом ограничений верхнего уровня) и скачать... И так далее, пока всё не будет скачано. И только потом (если конфликтов в предыдущих шагах не найдётся) приступать к сборке/тестированию/установке, но в чёткой последовательности...

Ты что-нибудь слышал про dynamic dependencies в перле? А про многопоточность?)

Нет, не слышал. Про что речь? Про recommends? Многопоточность: какое она имеет значение в данном случае?

Зависимости ставятся параллельно

Сейчас порву тебе шаблоны. Посмотри как cpan по-разному показывает зависимости у этих модулей :) https://metacpan.org/pod/korgwm https://metacpan.org/pod/X11::XCB

В cpm?

Да

Ну вот мне-то более желательна была бы как раз более воспроизводимая сборка (но без Nix/Guix)..

Я ж говорю, хочу кое что проверить и отпишусь потом

А где смотреть? Я сделал Dependency graph -> Table - и вроде всё показывает также . Только вот непонятно, как показ версий там включить?

Если что, install --workers 1 я пробовал, но оно странно работает. Параллелизм, собственно, сборки, судя по всему, выключает, но этапы resolve-fetch-configure всё равно делает группами по 5 штук и в каком-то случайном порядке, даже если зависимостей в cpanfile мало.

Смотри конкретно в: and possibly others dynamic_config enabled

https://metacpan.org/pod/Dist::Zilla::Plugin::Meta::Dynamic::Config "Normally this would not be required, but if you are providing your own Makefile.PL or Build.PL and asking questions, sensing the environment, etc. to generate a list of prereqs then dynamic_config should be set to a true value to satisfy the Meta specification." Т.е. если такой флаг стоит, то "там может быть всё что угодно" в зависимостях. Понятно, что у пакетов могут быть попросту неуказанные зависимости (и у нормального пакетного менеджера должны быть механизмы для дополнения/переопределения списка зависимостей у зависимостей). Но при массовой установке по спискам пакетов никто никакой ручной конфигурацией не занимается, и все версии, указанные в recommends/suggests тоже должны участвовать в разрешении вопроса, какие версии ставить для того замыкания пакетов, которое в итоге ставится в текущем запуске.

Не брат, ты похоже не до конца понял, при установке пакета оно может захотеть ещё зависимостей если найдёт у тебя в системе признаки для этой нужды

Это понятно. Но делать так без добавления хотя бы в recommends/suggests - плохо для кармы майнтейнера

> ставить для того замыкания пакетов шта

Если посмотришь на зависимости, например пакетов, приведённых чуть выше, легко увидишь циклы. Т.е. зависимости - это не дерево и даже не DAG, а граф, где наборs пакетов образуют замыкание.

да причем тут "замыкание"

Вообще есть нормальный термин для этого, циклы в графах, а вот замыкания вообще не из этой сферы.

Это давным давно устоялось в соответствующих пакетных менеджерах (guix, nix)

Граф это математическое понятие, так же как и цикл в графе с соответствующим мат аппаратом. В области есть устоявшееся граф зависимостей. А замыкание в графе это наркомания и придумка.

Ну, так научите материализовывать perl-пакеты, составляющие эти графы, безопасным образом. %)

Есть много вариантов не иметь проблем с зависимостями. Но самый простой - это всегда обновлять все пакеты до последних версий.

я вот думаю что разумнее обновлять до минимально требуемых :)

Сомневаюсь, что это прямо самый простой. Т.к. для этого, как минимум, у вас должны быть ресурсы на вычитку этих обновлений. Интересно, кто-то с серьёзными продами таким занимается?

И вот в таком и подобных подходах вопрос: как определить эту минимально требуемую версию?

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

Мы вычитываем только критичное, mojolicious как минимум, остальное или тесты или отвалиться в проде и будет хотфикс. В банках знаю там вычитывают все зависимости, но у них и время доставки фичи в прод от месяца и больше может быть.

прописать же