Помещает все зависимые проекты в репозитории проекта лучше?

Question

У меня есть проект, который использует пары (на данный момент ~ 6) зависимостей (другие библиотеки). Большинство из них находятся на лицензиях MIT/simplefied BSD, поэтому не следует просто копировать их в мое репо.

Было бы хорошей практикой поместить все эти библиотеки в мое репо и нажать их (и когда появятся новые версии, обновите их тоже)? Или мой проект репо должен содержать только файлы проекта (код, активы и т. Д.)?

Плюсы:

• здание так много проще, как у меня есть все, что мне нужно всегда рядом
• добавлены библиотеки означает, что я проверил мой проект, используя эти версии, как и другие (старше/новее) может создать некоторые проблемы

Против:

• наворотов в проекте репо
• должен обновить зависимости от стороны
• , если я хотел бы вставить и встроенные версии, я бы вставить много
• файлов и это заняло бы много места, так что, вероятно, прилипает к источнику только?

• некоторые библиотеки могут не так приятно лицензии и использовать их непосредственно (кроме требующих пользователю получить действительную библиотеку им самим) и поместить их в моем репо может сделать некоторые проблемы

• , имеющие большее количество проектов, чтобы сохранить до зависимостей будет означать, что я должен обновить их для всех проектов, в то же время (например, если я сделать некоторые другие проекты, в зависимости от текущего проекта (это библиотека), то все они будут иметь одинаковые dependnecies)

Answer 1

Короткий ответ: это зависит.

Длинный ответ:

Перед тем, как вопрос, является ли это целесообразным включать или не включать код в репозитории, вы должны спросить, является ли это целесообразно жестко контролировать зависимости или быть более расслабленным.

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

Например, предположим, что вы продаете аппаратное устройство, а ваш код является прошивкой устройства. В этом случае вы, вероятно, захотите жестко управлять зависимостями (для них требуются очень конкретные версии). Это дает вам полный контроль над всей системой, что упрощает тестирование системы и может быть важно, если ваше устройство подвержено определенным требованиям безопасности, безопасности или надежности (например, это медицинское устройство или зонд, отправленный в Плутон). В общем случае, если вы распространяете свой продукт в виде образа двоичной или файловой системы, вы, вероятно, захотите использовать фиксированные зависимости.

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

Как только вы знаете, как сильно вы хотите контролировать свои зависимости, вы можете выбрать механизм, используемый для управления ими. Вы можете использовать такой инструмент, как Apache Ivy, для автоматического получения зависимостей, GNU Autoconf для принудительного использования определенных версий или вы можете вывести код в свой репозиторий Git и самостоятельно его построить. Конкретный выбор не так важен; использовать все, что удовлетворяет вашим требованиям и является самым простым для вас и ваших пользователей.