А в чем проблема градла на 50+ сервисов?

Я пока не думал о том, чтобы вообще все в монорепо засунуть, для начала хотел только джава/котлин сервисы, а всякое пхп, ноджс и прочие хаскели не трогать.
Ошибку совершил?

Не знаю, у меня был какой-то кейс, в котором базелем просто невозможно было собрать что-то, потому что какой-то нужный мне ключ мавена (который у него под капотом всё равно был, по крайней мере, совместимость с оным) он не пробрасывал и не давал альтернативы

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

А можешь подсказать, в чем именно Базель так хорош для таких проектов?
Он быстрее работает или есть еще что-то?

Ну да, инкрементальная сборка + удалённое кэширование результатов очень сильно помогают на больших кодовых базах. Кроме того, базель поддерживает очень много языков в отличие от традиционных тулов и, даёт очень хорошую повторяемость билдов на разных тачках

Спасибо

а поделитесь опытом вкладывания в базель. Я глянул на него и чёт у меня прям кровь из глаз. Откуда вообще начинали и как оно в итоге?

я один из разработчиков selenium (selenium.dev), у нас монорепа была практически с рождения, то есть лет десять уже. за это время сменилось три инструмента. сначала был самодельный инструмент на базе rake. потом перешли на buck (это клон базеля, который сделал фейсбук, когда базель ещё не был в опенсорсе). потом, когда гугл таки открыл bazel — мигрировали на него. код написан на шести языках, причём куски на разных языках кое-где зависят друг от друга, так что сборка реально сложная, ни один "традиционный" сборщик не справляется (поэтому и пришлось сначала самодельный строить). так что я скорее сужу не по своим ощущениям, а по тому, как матерятся новые контрибьюторы, которые только начинают работать с проектом и раньше не имели опыта работы с монорепами и такими инструментами :)

пожалуй, главное, что их поначалу выбешивает — это отсутствие единого конфигурационного файла сборщика, где описаны все зависимости и правила сборки. это всё размазано ровным слоем по проекту, и это очень непривычно

может если для новых людей сложно вникать в суть монорепы, не стоит ли подумать о разделении?;)

а вообще рассматривался вариант распилить это все? или всех устраивает

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

если это разделить — проще вряд ли станет :)

зависимости-то от разделения не упростятся

спасибо!

а так по дефолту, как я понял, там что-то вроде CMakeList.txt, правильно?

я не знаю, что такое CMakeList, сорри

ушёл гуглить...

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

Нейронки понабежали, лул