Язык/платформа/независимый менеджер зависимостей

Question

Мне нужен менеджер зависимостей, который не привязан к определенному языку или системе сборки. Я изучил несколько отличных инструментов (Gradle, Bazel, Hunter, Biicode, Conan и т. Д.), Но никто не удовлетворяет моим требованиям (см. Ниже). Я также использовал Git Submodules и Mercurial Subrepos.

Мои потребности хорошо описаны в presentation Даниэль Пфайфер на совещании C++ 2014. Резюмируя цели этого инструмента зависимостей (обсуждаемый @ 18: 55 связанного видео):

• Не только не пакет менеджера
• Поддержки предварительно построенный или зависимости источника
• может скачать или найти локально - нет ненужных загрузок
• разгонов с использованием различных методов (то есть скачать или VCS клонов, и т.д.)
• Интеграция с установщиком системы - можно проверить, если Lib установлен
• Нет необходимости адаптировать исходный код каким-либо образом
• Нет необходимости адаптировать система сборки
• Кроссплатформенность

Дополнительные требования или разъяснения, я хотел бы добавить:

• Подходит для третьей стороны и/или версированы зависимости, но и способны указать не-версии и/или совместно разработанных зависимостей (возможно, заданных git/mercurial hash или tag).
• Предоставляет механизм, позволяющий переопределить указанное поведение выборки для использования некоторой альтернативной версии зависимостей по моему выбору.
• Не нужно вручную настраивать хранилище зависимостей. Я не против центрального местоположения зависимостей, чтобы избежать избыточных или круговых зависимостей. Однако нам нужна простота клонирования репо и выполнение некоторого сценария построения верхнего уровня, который вызывает менеджера зависимостей и создает все.
• Несмотря на то, что мне не нужно изменять мою систему сборки, очевидно, что некоторые сборки верхнего уровня должны обладать менеджером зависимостей, а затем передавать эти зависимости отдельным сборкам. Требование означает, что индивидуальные сборки не должны знать менеджера зависимостей. Например, если вы используете CMake для пакета C++, мне не нужно изменять его CMakeLists.txt, чтобы сделать специальными функциональными вызовами для поиска зависимостей. Скорее, менеджер сборки верхнего уровня должен вызвать менеджера зависимостей для извлечения зависимостей, а затем предоставить аргументы, которые CMake может использовать обычными способами (например, find_package или add_subdirectory). Другими словами, я всегда должен иметь возможность вручную выполнять работу менеджера сборки и менеджера зависимости верхнего уровня, а отдельная сборка не должна знать разницу.

Nice-на-есть:

• Путь опрашивать менеджер зависимостей после-фактум, чтобы найти, где зависимость помещался. Это позволило бы мне создавать привязки VCS для автоматического обновления хэша в метаданных зависимостей совместно разработанных зависимостей источника репо. (Подобно подмодулям или субреподам).

Answer 1

После тщательного поиска доступных технологий, сравнивая с менеджерами пакетов на разных языках (например, npm) и даже имея запуск на моем собственном инструменте менеджера зависимостей, я обосновался на Конане. После погружения глубоко в Конан, я нахожу, что он удовлетворяет большинство моих требований из коробки и легко расширяется.

Перед тем, как заглянуть в Конан, я увидел BitBake как модель того, что я искал. Тем не менее, это только linux и сильно ориентирован на встроенные дистрибутивы Linux. Конан по существу тот же самый рецепт функции, как бб и действительно кросс-платформенным

Вот мои требования и то, что я нашел с Conan:

• Не только менеджер пакетов
• Поддержка преднастроенным или источник зависимостей

Конан поддерживает релиз или Dev зависимости классические, а также позволяет упаковать источник. Если двоичные файлы с определенными конфигурациями/настройками не существуют в реестре (или «репозитории», на языке Конана), двоичный файл будет создан из источника.

• Может скачать или найти локально - нет ненужных загрузок
• Интегрированные с установщиком системы - можно проверить, если Lib установлен

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

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

• Fetches с использованием различных методов (т.е. загрузки, или VCS клонов и т.д.)

, реализующей функцией source рецепта обеспечивает полный контроль над тем, как зависимость извлекается. Конан поддерживает рецепты, которые выполняют загрузку/клонирование источника, или может «сделать снимок» источника, упаковывая его самим рецептом.

• Нет необходимости адаптировать исходный код каких-либо образом
• Нет необходимости адаптировать систему сборки

Конан поддерживает различные генераторы, чтобы сделать зависимости расходнога от выбранной системы сборки , Агностицизм от конкретной системы сборки - это реальная победа Конана и, в конечном счете, то, что делает управление зависимостями от подобных Bazel, Buckaroo и т. Д. Громоздким.

• Межплатформенная Python. Проверьте.

• Подходит для зависимостей сторонних производителей и/или версий, но также может указывать не-версии и/или совместно разработанные зависимости (возможно, заданные git/mercurial hash или tag).

Построенный с semver в виду, но можно использовать любую строку идентификатора в качестве версии. Кроме того, user и channel действуют как пространства имен для версий пакетов.

• Предоставляет механизм замены указанного поведения выборки использовать некоторую альтернативную версию зависимостей моего выбора.

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

• Нет необходимости вручную настроить хранилище зависимостей. Я не против центрального местоположения зависимостей, чтобы избежать избыточных или круговых зависимостей. Однако нам нужна простота клонирования репо и выполнение некоторого сценария построения верхнего уровня, который вызывает менеджера зависимостей и создает все. Несмотря на то, что мне не нужно изменять мою систему сборки, очевидно, что некоторые сборки верхнего уровня должны обладать менеджером зависимостей, а затем комбинировать эти зависимости с отдельными сборками. Требование означает, что отдельные сборки не должны знать менеджера зависимостей. Например, если использовать CMake для пакета C++, мне не нужно изменять его CMakeLists.txt, чтобы специальные функциональные вызовы находили зависимости. Скорее, менеджер сборки верхнего уровня должен вызвать менеджера зависимостей для извлечения зависимостей, а затем предоставить аргументы, которые CMake может использовать обычными способами (например, find_package или add_subdirectory). Другими словами, я всегда должен иметь возможность вручную выполнять работу менеджера сборки и менеджера зависимости верхнего уровня, а отдельная сборка не должна знать разницу.

Конан кэширует зависимости в локальном реестре. Это беспрепятственно. Канонический шаблон, который вы увидите в документации Конана, состоит в том, чтобы добавить некоторые конан-специфические вызовы в сценарии сборки, но этого можно избежать. Еще раз, если вы пишете скрипты сборки на пути префиксов потребителей и/или входные аргументы, вы можете передать информацию, а не использовать Conan вообще. Я думаю, что генераторы Conan CMake могли бы использовать небольшую работу, чтобы сделать ее более элегантной. В качестве резерва Конан позволяет мне писать собственный генератор.

• Способ опрашивать менеджер зависимостей после совершения факта, чтобы найти, где зависимость была помещена. Это позволило бы мне создавать привязки VCS для автоматического обновления хэша в метаданных зависимостей совместно разработанных зависимостей источника репо. (Подобно подмодулям или субреподам).

Генераторы указывают на эти места. И с полной способностью Python вы можете настроить это на содержание вашего сердца.

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

Другие вещи, которые я нашел в Conan:

• Конан обеспечивает возможность загрузки или компилированные инструменты, которые нужны в процессе разработки. Он использует Python virtualenv для упрощения включения/отключения этих настраиваемых сред без загрязнения моей системы.