Nix как нативный пакетный менеджер для ROS

В очередной раз на ROS Discource разгорелась жаркая дискуссия по поводу интеграции Nix в ROS. Автор обсуждения изложил основные проблемы сборки и управления зависимостями в ROS, а также предложил рассмотреть вопрос использования nix как нативной системы сборки пакетов.

CTO Open Robotics не слишком погружался в тему (мало знает о nix), но признаёт что лучшие использовать уже существующие инструменты, чем разрабатывать свои собственные (на момент разработки colcon альтернатив не было). Также он отметил, что ament-cmake, помимо сборки и управления зависимостями, выполняет также работу по генерации обработчиков для IDL-интерфейсов. Этого никс не делает по умолчанию (прим. ред. - и не должен, это задачи всяких хуков).
Разработчик Zenoh признаёт, что нужно слишком много поменять в текущем workflow публикации пакетов. Это слишком фундаментальная задача.
Один из Great Contributors высказал позицию, что воспроизводимость сборки не имеет значения, потому что репозитории git и пакеты pypi появляются и исчезают (прим. ред - видимо, он не в курсе кэш nix'а - даже если исходник будет потерян или перемещён, то сборка всё равно не нарушится). Также он отметил, что ROS как раз был очень хорош, потому что в нём было легко начать разработку, а с nix это может быть сложнее.
Один из контрибьюторов nix-ros-overlay дал подробные ответы на все возникшие вопросы и дал понять, что можно в ROS ничего и не менять - пользователи nix-ros-overlay уже привыкли жить как есть.
В общем, рекомендую топик к прочтению, если хотите разбираться с основными аспектами применения nix в контексте ROS и связанными с этим стереотипами.

Что также тут можно отметить?

Проблемы с управлением зависимостями существуют и признаются участниками сообщества. Однако, устоявшийся порядок сборки и дистрибьюции пакетов, построенный на vcstool/ament/bloom/colcon/rosdistro/apt, менять будет слишком накладно. Даже если представить, что кто-то пойдёт на столь решительный шаг, то будет сделано буквально следующее:
1. Отказ от поддержки создания ROS для любых других источников зависимостей, кроме nixpkgs (без apt, без dmf, без conda, без поддержки Windows без WSL, без yocto, без gentoo).
2. Поскольку использование нескольких менеджеров пакетов больше не является обязательным требованием, удаляются package.xml, зависимости задаются в файлах nix flake вместо содержащихся в них ключей rosdep.
3. Удаляются bloom и superflore; больше не нужно генерировать файлы конфигурации nix, поскольку они уже будут в репозиториях, вместо package.xml
Я вижу эти шаги маловероятными на текущем этапе. Более вероятны перспективы в виде изключения из процесса дистрибьюции централизованного rosdistro, репозиториев релизных пакетов и их замены на сборку из исходников напрямую. Теоретически это можно сделать через какой-то генератор, который находит upstream-репозитории, строит на базе разных веток .nix пакеты для соответствующих дистрибутивов ROS. Теоретически это можно сделать через какой-то генератор, который находит upstream репозитории, строит на базе разных веток .nix пакеты для соответствующих дистрибутивов ROS.

Итак, ROS и его инфраструктура представляют собой экосистему для разработки, сборки, дистрибьюции приложений робототехники, основывающуюся во многом на централизованных репозиториях (github) исходных и собранных пакетов. Как и любая другая экосистема, ROS существует благодаря стандартам/протоколам взаимодействия. Эти стандарты двояки: с одной стороны они сглаживают транзакционные издержки на кооперацию (делают проще взаимодействие участников), а с другой стороны - препятствуют внедрению нового - изменять стандарты в системах с большим количеством акторов довольно сложно. Хотя, откровенно говоря, инфраструктура ROS довольно централизованна и представить её работу без github затруднительно.

Сейчас консенсус состоит в том, что nixоводы сделали надстройку в виде nix-ros-overlay, которая ничего не меняет в этом устоявшемся порядке работы экосистемы и появления таких технологий как nix/guix стоит ожидать не ранее анонса ROS 3.

#ros #nix #discourse