Git подмодули и арматура

Question

Мое приложение использует Mochiweb. Как я понимаю, rebar выбирает последнюю версию Github, когда я бегу make, потому что линия в rebar.config:

{deps, [ 
    {mochiweb, ".*", 
    {git, "git://github.com/mochi/mochiweb.git", "master"}} 

Мое приложение имеет VCS и это мерзавец. Таким образом, по существу, у меня есть один репозиторий Git внутри другой:

myapp 
.git 
deps 
    mochiweb 
    .git 
src 
etc 

Я знаю, что добавление репозитория Git внутри другой не очень хорошая идея (git add .). Вместо этого следует использовать функциональные возможности подмодулей Git.

Итак, я добавил каталог deps/mochiweb в качестве подмодуля в основной репозиторий git.

Проблема заключается в том, что, когда другой разработчик клонирует главный репозиторий он должен init и update Подмодули первым, чтобы получить deps/mochiweb (в противном случае было бы пусто).

Если разработчик просто запускает make право после того как он клонирует главный репозиторий, то Makefile говорит следующее:

ERROR: Dependency dir deps/mochiweb failed application validation with reason: 

{missing_app_file,"deps/mochiweb"} 

make: *** [all] Error 1 

Мой вопрос: Что такое правильный способ добавления другого приложения к DEPS из Приложение Erlang позволяет легко обновлять другие разработчики без использования подмодулей git?

Answer 1

Что такое правильный способ добавления другого приложения к DEPS в качестве Erlang приложения, чтобы легко обновления от других разработчиков без использования GIT подмодулей?

Добавьте приложение к rebar.config и использования:

./rebar update-deps 

Для обновления. Первый раз, вам нужно использовать:

./rebar get-deps 

См: https://github.com/basho/rebar/wiki/Rebar-commands

Теперь вернемся к вашей ошибки.

Мое ощущение, что у вас есть (почти) пустая директория для mochiweb в ваших папках, возможно, в результате игры с подмодулями Git. Когда вы запускаете команду get-deps, арматура тихо отбрасывает mochiweb, так как каталог уже существует. Но он ожидает приложение OTP и ищет файл mochiweb.app, которого нет (каталог пуст). Поэтому ошибка. Если моя интерпретация верна, то вы можете просто сделать:

rm -rf deps/mochiweb 
./rebar get-deps 

Имея взгляд на ваш rebar.config бы помочь, хотя.

Answer 2

Я думаю, что вы ищете команду арматуры get-deps. Посмотрите на Makefile и rebar.config, используемые Riak для хорошего примера.

Answer 3

В наших внутренних проектах Erlang мы используем подход Git subtree merge к ссылочным зависимостям.На мой взгляд, даже если rebar get-deps это Handly способ получить зависимости для github размещенного проекта является не то, что хорошо в корпоративной среде:

1. github должен быть доступен из любой сборки-машины (и источники для зависимостей жестко закодированы в rebar.config)
2. Вы полагаетесь на зависимое проекционное видение, которое не так точно (можете ли вы указать на конкретную фиксацию?). Не только невозможно воспроизвести состояние вашего проекта в прошлом (со всеми зависимостями того времени), но еще хуже, ваш проект также можно легко сломать, когда какая-то зависимость обновляется на github (без обновления его версии) ,
3. Что делать, если вы хотите настроить зависимый проект? Как небольшое изменение в файле rebar.config зависимого проекта?

Таким образом, вместо get-deps мы используем отдельную ветвь (+ пульт дистанционного указывая на конкретные github проекта) для каждого зависимого проекта и мерзавца поддерева объединить его в «DEP» каталог на нашем филиале проекта. Эффективно мы храним все зависимость в основной отрасли, но таким образом мы решаем все вышеуказанные проблемы:

1. Вы получаете всю базу коды, потянув за основную ветвь проекта (или DEV и т.д.) из наших внутренних хранилищ Git. Он сразу же можно построить.
2. Точные версии всех зависимостей - это поддерево, объединенное в нашу основную ветку, и мы обновляемся до более новой версии зависимостей только тогда, когда нам нужно/нужно: просто переключиться на ветвь зависимости, сделайте git pull, а их поддерево слить некоторую конкретную версию зависимость от основной ветви. В любой момент вы можете получить любую прошлую версию всего проекта.
3. Зависимость может быть настроена в его собственной ветке (или другой настраиваемой ветке), когда пришло время обновить зависимость: вам придется git merge с последним кодом с вашими изменениями, но это обычно не проблема. Вы даже можете указать свой пульт в свой собственный репозиторий (разветвленный на github или внутренний).

Конечно, мы не будем публиковать наш проект в этой форме (включая все зависимости) в «github», но вы можете удалить все зависимости (удалив папку «dep») на отдельной ветке и опубликовать результат , Недостатком этого подхода является немного хлопот с обновлениями зависимостей: вместо rebar get-deps вы должны сделать git push + git merge -s subtree для каждой зависимости, которую хотите обновить, но это всего лишь следствие строгого управления зависимостями и простоты сборки.