когда из билд-системы вызывается другая билд-система, ты жертвуешь либо параллелизмом, либо юзабилити. дизайн, который прибивает гвоздями что-то одно (параллелизм?), это просто выбор в дизайн-спейсе. Другие системы дают тебе или другое, или, что ещё лучше, ручку на покрутить самостоятельно, под твои задачи. Вполне рациональный дизайн, для реального мира.

Сообщите когда будет ваш мастеркласс по дизайну - постараюсь посетить )

Его не будет )

Если перейти от частного случая к таким общим и обтекаемым фразам - да, все так. Напомню, начало беседы началось про дать судо в процессе сборки ребаром. Все остальное - вырвано из контекста. Так вот если не выходить из контекста изначального вопроса , то именно его формулировка вызывает "удивление" относительно дизайна подхода. На что и указали автору вопроса. Но он почему-то не смог принять и начал "защищаться"

А вообще, костылять частные случаи - вполне норм. Если это не требует дальнейшего развития и сопровождения. Главное - решить бизнес задачу. Ведь так?)

правильно так - "я не знаю есть или нет у скриптов под управлением rebar доступ к стандартному вводу, но зато умею порассуждать на тему архитектуры"

коллеги, а кто-нибудь уже заюзал 22ой ОТП, особливо в части мультиплексирования? насколько ощутили прирост в обмене блобами?

Гайз а кто-нибудь использует внутри nif-ок internal api vm для atomics, spinlocks, etc ?

А rebar не умеет фитчить git с подмодулями ?

или использовать подмодули git это слишком плохая архитектура для rebar?

подмодули - это плохая архитектура даже для гита кмк :)

а чем это отличается от зависимостей в rebar?

Тем, что ребар - система управления зависимостями, а Гит порождён и развивается как система контроля версий (типа). Субмодули тащат элементы первого во второй, причём довольно плохо композируемо. Если бы гит был универсальной системой контроля-версий-зависимостей, можно было бы увидеть логику в этом. Но нет же, это всё ещё SCM, но с каким-то эмбрионом ad hoc костыля сбоку.

в git есть этот инсрумент и работает достаточно неплохо (и уж точно лучше чем поддержка git в rebar). ипользую много лет.
но насчет архитектуры спорить не буду.

у тебя наверху субмодули, илт в субмодулях тоже субмодули?

подмодуль в nif у зависимости , я уже решил вопрос собственно в makefile  nif,
rebar предлагает это  (--recursive) решать через hooks какие-то. при этом документация на rebar просто восхитительная )

плохая композируемость:
- Ты не можешь объявить субмодули и забыть на год: у тебя управление зависимостей проникает во многие фазы управления проектом.
- То, что в проекте есть субмодули, должно быть известно пользователям проекта, чтобы это начало работать.
— То, что в зависимостях (при использовании иной билд-системы) могут появиться субмодули, становится головняком топового проекта.

Так что фича-то может и работает, но плохо композируется сама с собой и с внешним миром, что позволяет нам её осуждать.

- пользователи проекта еще могут знать о ветках, бранчах и тагах и эта опция в rebar поддерживается
- то что топовый проект не должен спотыкаться о сборку зависимости согласен,  
 в ребар нет возможности указать зависимость от подмодуля прям в своем проекте. вот у erlang.mk например, есть.
git git-subfolder git-submodule

нафига rebar, если на каждый чих надо его бросать и кропать makefile или набирать магические сочетания {{{hook for hook so}}}

но зачем делать настолько изощренные проекты, что им не хватает ребара?