В чем разница между Bazel и Gradle?

Отказ от ответственности: я работаю над Bazel и плохо знаком с Gradle. Однако один из моих коллег написал сравнение двух систем, которое я перефразирую здесь:

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

Gradle ценит те же принципы, что и Bazel, то есть команда Gradle уделяет большое внимание производительности (инкрементные сборки, распараллеливание и выполнение, демон Gradle), корректности (проверка «актуальности» на основе содержимого) и воспроизводимости. (богатая поддержка декларативного синтаксиса, управления версиями зависимостей, явно объявленных зависимостей). И «Базел» уважает потребность в гибких макетах проектов.

Нюанс в том, что Gradle хочет продвигать хорошую практику, а Bazel требует этого. Gradle стремится найти золотую середину между опытом Ant (свобода определять собственную структуру проекта с несогласованными результатами) и опытом Maven (принудительное применение лучших практик без возможности варьирования потребностей проекта). Bazel считает, что гибкая поддержка проекта возможна без ущерба для надежных гарантий, обеспечивающих его мощные рабочие процессы.

Ни одна из этих философий не является более «правильной» - какой инструмент лучше всего подходит для проекта, зависит от его ценностей.

Обзор Gradle

Gradle - это очень гибкая система, которая позволяет пользователям легко создавать полные, надежные потоки сборки с минимальными ограничениями на то, как они организуют свои проекты. Он делает это, предоставляя мощные строительные блоки (например, автоматическое отслеживание и извлечение зависимостей, тесно интегрированную поддержку плагинов) с универсальным, полным по Тьюрингу интерфейсом сценариев, который может комбинировать эти блоки по желанию пользователя.

Gradle подчеркивает следующие особенности:

• Простая миграция с других систем. Gradle легко адаптируется к любой проектной организации и легко реализует произвольные структуры рабочего процесса. Он изначально понимает задачи Ant и изначально интегрируется с репозиториями Maven и Ivy.
• Модель сценариев с высокой степенью расширения. Пользователи реализуют всю логику сборки, написав сценарии Groovy. «Сборка» - это просто упорядоченное по зависимостям выполнение общих задач, которые по сути являются открытыми, переопределяемыми, расширяемыми определениями методов.
• Расширенное управление зависимостями. Версионные зависимости могут быть объявлены и автоматически размещены из внешних репозиториев кода, локальных файловых систем и других проектов Gradle. Выходные данные сборки также могут автоматически публиковаться в репозиториях и других местах.
• Тесно интегрированная система плагинов. Плагины - это просто наборы задач, организованные для облегчения желаемого рабочего процесса. Многие из «основных» функций Gradle фактически реализованы через плагины (например, Java, Android). Плагины (по своему усмотрению) тесно взаимодействуют с логикой скрипта сборки. Плагины имеют глубокий доступ к основным структурам данных Gradle.

Обзор Базеля

Bazel возникла из-за необходимости надежно и эффективно создавать внутренние проекты Google. Поскольку среда разработки Google необычно велика и сложна, Bazel предлагает необычайно надежные гарантии целостности своих сборок и необычно низкие накладные расходы при их достижении.

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

Базель подчеркивает следующие особенности:

• Корректность. Сборки Bazel предназначены для всегда правильного вывода, точка. Если два пользователя вызывают одну и ту же сборку в одной и той же фиксации с одинаковыми флагами Bazel на разных машинах, они увидят одинаковые результаты. Инкрементные сборки так же надежны, как и чистые сборки, что делает последние практически ненужными.
• Производительность. Сборки предназначены для выполнения с максимально возможной скоростью с учетом доступных для них ресурсов. Задачи можно распараллеливать настолько, насколько позволяют их цепочки зависимостей. Ненужная работа никогда не выполняется (т.е. «актуальные» задачи всегда пропускаются). Естественно, что работа может быть отдана удаленным исполнителям, чтобы преодолеть ограничения локального компьютера.
• Воспроизводимость. Любой экземпляр сборки можно точно воспроизвести в любой среде. Например, если в отчете об ошибке говорится, что версия X программного обеспечения Y не работает в производственной среде Z, разработчик может точно воссоздать ее на своем собственном компьютере с уверенностью, что они отлаживают то же самое.

Поскольку ссылки на статьи имеют тенденцию умирать, вот краткое изложение взгляды команды Gradle на Bazel (большинство из них прямо взято из статьи, опубликованной в марте 2015 года):

Он был разработан для решения уникальной проблемы Google; массивная монолитная кодовая база (сотни миллионов LOC).

Преимущество распараллеливания, которое в настоящее время предоставляет Bazel, будет соответствовать «нашей предстоящей новой конфигурации и модели компонентов» (не забывайте дату статьи здесь).

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

Bazel не создан для расширяемости (хотя с тех пор команда разработчиков Bazel возражает против этого, заявляя, что они работают над расширяемостью).

Скорость оптимизирована вокруг идеи, что все транзитивные зависимости хранятся в одном большом репо; все библиотеки и инструменты зарегистрированы в этом центральном репозитории. Большинство предприятий имеют более распределенные требования к управлению зависимостями.

Bazel - это только * nix, он не работает в Windows. Это исключает большое количество потенциальных предприятий.

Нет экосистемы плагинов.

Gradle в основном используется в экосистеме JVM (Java, Ggroovy, Scala, Kotlin ...). Если ваш проект находится в этой области, и вы должны задать вопрос, Gradle или Maven будут лучшим выбором. Чтобы устранить неполадки в сборке Gradle, вы будете разбираться только с экосистемой Java и JVM.

В основе Bazel лежит способность обнаруживать инкрементные изменения (а также распределенный кеш сборки) и позволять вам реагировать, применять плагины / правила для достижения инкрементных сборок. Чтобы настроить и поддерживать это, требовалось немного знаний в CPP, Java и Python (Skylark), а также знания системного администратора. Опять же, если вам нужно задать вопрос, я думаю, что Gradle или Maven были бы более дешевым вложением. С Bazel вы можете создавать любые языки, в зависимости от вашего определения, с большей мощностью, но за свою цену.