Подмодули для плагинов или для зависимостей?

Question

Предположим, что Project X является базовым проектом, а Project Y зависит от X. Project Y может быть плагином для Project X или, возможно, это отдельное приложение, для которого требуется Project X другим способом.

IВсе это время я думал, что Проект Y должен быть суперпроектом, а Проект X должен быть подмодулем Проекта Y.

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

Answer 1

Это зависит, но в общем случае я бы сказал, что подмодули (или могут быть) для обоих.

Очевидно, что если Проект Y является зависимостью (например, внешней библиотекой) Проекта X, это должен быть подмодуль.

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

Answer 2

Если ProjectY может жить, ничего не зная о ProjectX (что может быть в случае, если это плагин для X), не может быть суперпроектом.

Если требуется, чтобы X был каким-то образом завершен, тогда да, это мог бы быть суперпроект, чтобы ссылаться на X в его дереве (как объяснено в истинной природе подмодулей ).

В компонентном подходе истинным суперпроектом будет третий проект, который ссылается на правильную версию ProjectY и ProjectX для записи точной конфигурации (то есть списка исправления), необходимые для работы всего проекта.

---

ОП добавляет правильный вопрос: где хранится зависимость (от Y до X)?

Если кто-то использует компонентный подход и имеет суперпроект ProjectZ, а ProjectY зависит от сборки ProjectX, не будем ли мы включать ProjectX в качестве подмодуля в репозиторий ProjectY, но только в ProjectZ?
Это будет означать, что ProjectY не может быть построен сам по себе, что делает его (из-за отсутствия красноречия) своего рода «подразумеваемым подмодулем».

Если у вас есть только 2 компонента, один из которых зависит от другого, конечно: вы можете напрямую объявить ProjectX как подмодуль ProjectY.

Но если ProjectY не может быть построен сам по себе, он все равно не является "завершенным" (как в "автономном") проектом.
Следовательно, глобальный родительский «ProjectZ», где хранение этой информации о зависимостях вне ProjectY имеет свои преимущества:

1. сделать пути к каждому модулю более видимыми непосредственно из корня ProjectZ (вместо того, чтобы хоронить ProjectX потенциально глубоко внутри ProjectY, делая эту зависимость менее видимой для клиентов ProjectY)
2. объединение версий ProjectX (если несколько модулей нуждаются в ProjectX, то ссылка на него один раз в ProjectZ четко объявляет «одну официальную версию» ProjectX, которую должны использовать все остальные модули)