Comments 19
Хранить зависимости в buildSrc это ж кошмарная идея. Как и использовать buildSrc в 2к22 в целом. Любое изменение buildSrc инвалидирует кэши. Поменяли версию зависимости и вот сидите, огребаете.
Для зависимостей вообще-то есть Version Catalog
Если уж ТАК хочется хранить зависимости в коде можно использовать Composite builds
Спасибо.
Version Catalog рассматривали, но не захотели брать:
Плохой комплит, и его нет вообще в groovy-based билд-скриптах.
При ctrl/cmd клике проваливаемся в сгенерённый из TOML код, а не в сам TOML.
Все те же минусы (инвалидация при добавлении/удалении зависимости), что и при нашем подходе.
Очень неудобное выстраивание дерева зависимостей, так как группировка через
_.Само дерево у нас уже было написано руками, как было удобно, и комплит по такому дереву отлично работает, проваливание из
build.gradleв место декларации тоже работает.
А чем предлагается заменить buildSrc для плагинов, которые нигде не шерятся?
includeBuild разве не страдает теми же инвалидациями build classpath?
А чем предлагается заменить
buildSrcдля плагинов, которые нигде не шерятся?
В плане? Не особо понял проблему. По факту же buildSrc это тот же includeBuild просто добавленный в classpath со старта и везде. Причем Gradle в итоге откажутся рано или поздно от buildSrc совсем и превратят его уже в явный includedBuild
includeBuildразве не страдает теми же инвалидациями build classpath?
Да, но не совсем, ничто не мешает распихать по разным includedBuild
Version Catalog кстати хорош тем, что можно явно иметь зависимости между композитными билдами и кодом основного проекта. Но да, возможно в Groovy все не так хорошо, работал с ним только в Kotlin DSL
//for autocomplite and highlight dependencies from groovy build.gradle files
api(files(libs::class.java.superclass.protectionDomain.codeSource.location))В груви тоже работает, но нужно однострочный хак добавить в какой-нибудь корневой модуль includedBuild'а
Но тема с проваливанием в сгенерённые классы - жиза и боль
А вы не пробовали сравнить время сборки если один и тот же модуль написать на Java и на Kotlin? Есть ощущение что код на Java собирается быстрее и итоговый размер меньше.
Модуль на Java собирается наиболее быстро. Модуль на Kotlin - медленнее. Смешанный модуль (исходники Java и Kotlin вперемешку) - ещё медленнее. И ещё, существенным фактором является наличие кодогенерации в модуле (использование Dagger2, и др. аналогичных dependency injection фреймворков), тогда в сборку модуля подключается шаг apt / kapt, который по времени может быть, приблизительно как компиляция Kotlin.
Но чисел мы дать не можем, т.к. целенаправленно такое сравнение не делали.
Очень не хватает графики сравнения скорости сборки до и после оптимизаций
Привет, Кирилл!
Да, действительно небольшое упущение от нас.
Мы занимались улучшениями скорость сборки начиная с прошлого лета, поэтому довольно сложно сейчас померять кумулятивный эффект от всех проделанных изменений.
Как правило замеряли какую то конкретную гипотезу.
Возможно кто-то из моей команды или я сам позже запостит в комментарии какие-то конкретные числа ДО и ПОСЛЕ всех проделанных работ.
Все это хорошо, но не можете ли вы снова включить "Балабобу"? Ну хотя бы по API пусть будет доступна - умельцы же сделали много телеграм-ботов, подключенных к ней. Была же нормальная демка! Чем она помешала? Тем фильтры стояли на политику и религию даже, так что результаты не могли никого оскорбить.
Сегодня же многие интересуются нейросетями, хотят попробовать крупные модели на практике, а это проблематично. Все действительно крупные сети (dalle-2, Imagen, ruGPT-3 13 млрд. параметрами) закрыты для общественности. Это весьма неприятно - хочешь попробовать технологию, а не можешь. Да, Яндекс выложил в открытый доступ версию YaLM со 100 млрд. параметрами, но вот скажите, какой рядовой пользователь сможет ее запустить? Это нужно либо целый набор дорогостоящего оборудования, либо аренда мощных облачных серверов - в общем, без вариантов. А "Балабоба" с 3 млрд. параметрами была доступна прямо в браузере с графической оболочкой и позволяла проводить разные эксперименты. Очень жаль, что она уже полгода не работает. Многие не успели попробовать. Надеюсь, включите?
Опять советы из 2017. Часть флагов уже задепрекейчена, часть давно включена по умолчанию. Но они так и кочуют из гайда в гайд.
Про флаги gradle для котлина - вообще 0 упоминания.
Можете развернуть мысль тут?
Да, часть флагов постепенно включается командой Gradle, в мажорной 8.0 тоже что-то включат.
Про флаги для котлина было бы интересно почитать.
Мы действительно выставляем некоторые флаги, специфичные для Kotlin Gradle Plugin, однако почти все они довольно специализированные, и рекомендовать какие-то флаги для всех было бы ошибкой.
Не мне конечно Яндекс учить, но как по мне вы что-то не то делаете, ибо на прошлой работе прила весила 500 Мб и только росла, однако собиралась пару минут в лучшем случае. На нынешней работе пишу с нуля и нормально, поэтому весит всего 14 Мб (причем со сторонней либой для анимаций) и собирается буквально может пару десятков секунд (но оно и понятно). Но бОльшая проблема это все же вес, у нас тестировщикам приходится самим осваивать IDE и системы контроля версий чтобы самим собирать проекты, ибо 500 Мб умаешься им в телегу кидать. Вот боимся мы своих велосипедов, в итоге все собирается 20 минут из-за либ, делающих то, что можно сделать двумя строками.
Не мне конечно Яндекс учить.....
ибо 500 Мб умаешься им в телегу кидать
поржал :) у меня все.
Это смех без причины, без обид, зачем тягать файл на полгига, когда можно тягать файл на пару десятков мегабайт. У многих горит оттого что прилы стали такие тяжелые, хотя типа как у всех памяти достаточно на устройствах.
да какие уж тут обиды, вы даже не поняли глубину вашего дна.
зачем кому-то что-то кидать в телегу? что за бред-то такой. чем вы там вообще занимаетесь? вроде и тестировщики есть, и система контроля версий, и велосипедов опасаетесь, но в итоге все равно страдаете фигней.
О, все, другое дело, тогда претензию понимаю! В это сложно поверить, но компания одна из самых известных, скорее всего вы даже пользуетесь иногда ее продуктами, название по понятным причинам давать не буду. Скорее всего вы просто забываете где живете и не знаете как все работает иногда в этой стране. Да и вообще, ко мне какие претензии, как будто бы я начальник и так построил бизнес-процессы и в итоге мы там "страдаем фигней", даже лиды не могут влиять на это, хотя это уже руководящая должность по сути, но они могут влиять только на сам процесс разработки. А я просто наемный работник. Речь шла о том что прилы раздуваются настолько, что весят по полгига и с этим возникают соответствующие трудности, только и всего, остальное пожалуйста не к мне.
Самый простой способ — собирать метрики прямо со всех разработческих машин [...] Плюс в том, что мы видим данные от пользователей и понимаем, насколько они страдают. Минус — это чрезвычайно нестабильная метрика[...] В итоге эта метрика будет сильно неустойчивой
Да, если машин, с которых собирается метрика, мало - получаем большой разброс значений. Но можно считать процентили за сутки или неделю. В этой метрике самое главное - это реальное время сборки у пользователей, она позволяет избежать риска "отрыва от реальности", когда метрики на двух избранных супер-ноутбуках идеальны, а разработчики на своих ноутбуках страдают.
самое главное — она не позволит искать изменения, создающие ухудшения
Она не позволяет оперативно обнаруживать небольшие изменения (сопоставимые с разбросом собираемых значений) и соотносить их с изменениями в конкретном пул-реквесте. Но она позволит обнаруживать ухудшения по процентилям за сутки или неделю из-за тех причин, которые отсутствуют в метриках на чистых лабораторных ноутбуках (сеть, сопутствующий установленный софт, антивирус, CPU и память, даже температура в офисе - про термальный троттлинг хорошо говорил Андрей Акиньшин в https://habr.com/ru/company/jugru/blog/486712/).
Ещё один бонус - метрика времени сборки у реальных пользователей даёт ответ, какие конфигурации быстрее (MacOS или Linux, Intel или M1 и т.д.) и предпочтительнее для разработчиков.
Как мы ускоряли сборку Android-приложения из двух миллионов строк кода