а вот такое скажите. проект состоит из различных частей (web api, сбор данных, обработка данных и т.д.). сейчас всё это живёт в одном проекте (использую leiningen), в разных ns. в какой момент полезно задуматься о разделении всего на разные подпроекты (в том же lein)? по отдельности разные части использоваться не будут, т.е. в итоге это всё равно будет один uberjar

Я б забил. Вон у гугла - монорепо. У тебя вряд ли больше кода

Или когда кусок кода станет похож на библиотеку. Или когда тебе станет казаться, что проще с парой репозиториев работать, чем с клубком билд скриптов

Либо когда чуваки начинают абы-куда коммитить, и кроме как "разделить на репы и поурезать права" рычагов влияния нет

Я не в первый раз слышу про монорепо у гугла

Расскажите подробнее пожалуйста

Я знаю, что fb, вроде как монорепо

А что рассказывать? 1 репо на все проекты

По интернету хватает бложиков о сравнении мульти- и монорепов с гуглом как пример

Как мне кажется: каждый д*ит как захочет, и есть дела поважнее обычно

Да не, меня удивило, что люди про монорепо у гугла говорят, а знакомые из гугла говорят, что у них там свои репы попроектно. Но похоже действительно монорепо

Мне кажется равняться на гугл или фейсбук в таких вопросах не стоит, если что 🙂

Насколько я понял они монорепу поднимали чтобы радикально упростить тулинг для охулиарда разработчиков

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

@be9 я бы на твоем месте не заморачивался на распилку приложения

да, я пока решил забить

монорепо это классно, год назад перевел все свои проекты на него - прям радосать и счастье 🙂

http://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext Вот это самая детальная статья про монорепо у гугла. Но вообще дофега контор так код хранит и большие и мелкие, не обязательно иметь 100500 человек.

Особенно счас это легко делать когда ФБ заопенсорсил свою билд систему https://buckbuild.com и гугл свою https://bazel.build

@artemyarulin поделись, чем это именно тебе удобно. ладно там гуглы, у них свои заморочки

Подскажите, а что это за штука такая?

#_(def train-csv (load-csv “resources/train.csv”))
#_ — вот эта?

>Ignore next form (#_) >The form following #_ is completely skipped by the reader. (This is a more complete removal than the comment macro which yields nil).

Спасибо!

я так понимаю buckbuildне поддерживает clojure?

жизнь слишком коротка для еще одной билд системы

@a.espolov Официально clojure ни buck не bazel не поддерживает, но есть моя либа https://github.com/artemyarulin/clojure-clojurescript-buck которая генерит lein проекты по сути динамически и есть https://github.com/ladderlife/loonie более верная реализация, но в последний раз когда я смотрел требовал кастомного патча на компилтор @be9 В принципе все теже плюсы что и в статье о гугле 1) breaking changes делать легко - поменял либу, поменял все ее вызовы в других либах, все одним комитом 2) CI я настроил один раз год назад. Чтобы создать новый проект/либу все что нужно это грубо говоря echo "cljc_module(name='lib',src='lib.cljc',test='lib_test.cljc’)” > BUCK && touch {lib,lib_test}.cljc. После этого buck/CI при изменении будет все пересобирать, запускать тесты (так как это CLJC модуль то дважды в JVM/JS енвайронменте, мне не надо об этом думать) 3) Так как стоимость создания либ близка к нулю - то в итоге я их создаю чаще/больше. У меня по сути 2 продукта в монорепо, но около 80 отдельных либ/проектов со своимим зависимостями, тестами, etc. 4) У меня сейчас есть Clojure/ClojureScript/React Native(iOS|Android)/PureScript модули, любой из них я могу всегда сбилдить по buck build [module-name] и потестить buck test [module-name], это сильно облегчает когда такой зоопарк. Деполой туда-же 5) Отсутсвие версионности внутри репо - все всегда использует последнюю версию. Если я поменял модуль A а он используется библиотеками B и C то мне нужно их поменять в том числе сразу. Т.е. не бывает такого что ты проект не трогал пол года - вернулся к нему а он outdated и вперед апдейтить его, приводить в жизни 6) Это больше про Buck/Bazel чем про монорепо но возможность заимпелементить и переиспользовать билд шаги нужные именно мне https://pbs.twimg.com/media/Crp2jNWWAAAVIuR.jpg (CLJS код + нативный тест на ObjC). Как понимаю boot делает что-то похожее 7) Банально проще - докеры, subtree, submodules, прочая магия чтоб сделать один интеграционный с беком/фронтом и мобайл заменяется просто тестом

@artemyarulin а есть шансы из приватной монорепы билдскриптами выпубликовать какую-нибудь публичную библиотечку? или нужно явно вырезать в отдельную репу?

@misha ага есть, фейсбуки всякие используют самописные экспортеры (не могу счас найти их тулзу, там DSL для php (sic!) да). Я же по старинке git subtree - у меня гдет 7-8 проектов так открыты

когда-нибудь надо потратиться - раздуплиться в этом хозяйстве

а нет нашел кста https://github.com/facebook/fbshipit

но у меня руки так до него и не дошли