Положить ли все зависимости проекта в репозиторий проекта?
У меня есть проект, который использует пару (на данный момент ~ 6) зависимостей (другие библиотеки). Большинство из них имеют лицензии BSD в MIT / просто зарезервированы, поэтому не должно быть проблемой просто скопировать их в мое хранилище.
Будет ли хорошей практикой помещать все эти библиотеки в репозиторий и отправлять их (и когда появятся новые версии, обновите их тоже)? Или репозиторий моего проекта должен содержать только файлы проекта (код, ресурсы и т. Д.)?
Плюсы:
- Строительство намного проще, так как у меня есть все, что мне нужно, всегда рядом
- добавленные библиотеки означают, что я протестировал свой проект с использованием этих версий, так как другие (старые / новые) могут создавать некоторые проблемы
Минусы:
- раздувать в репо проекта
- обновлять зависимости вручную
- если бы я хотел вставить также встроенные версии, мне пришлось бы вставлять много
- файлы, и это заняло бы много места, поэтому, вероятно, придерживаться источника
только? -
у некоторых библиотек может быть не очень хорошая лицензия, и их использование напрямую (кроме необходимости требовать от пользователя получения действительной библиотеки самостоятельно) и размещение их в моем репо может создать некоторые проблемы
-
наличие большего количества проектов для сохранения зависимостей означало бы, что мне нужно обновлять их для всех проектов одновременно (например, если я делаю некоторые другие проекты в зависимости от текущего проекта (это библиотека), тогда все они будут иметь одинаковые зависимости)
Решение
Краткий ответ: это зависит.
Длинный ответ:
Прежде чем задаться вопросом, уместно ли включать код в ваш репозиторий, вам следует спросить, уместно ли жестко контролировать зависимости или быть более спокойным.
Ответ на этот вопрос зависит от того, как вы распространяете свой проект, чего хотят ваши клиенты / пользователи, нужно ли вам вносить какие-либо изменения исходного кода в зависимости и любые другие требования проекта.
Например, предположим, что вы продаете аппаратное устройство, а ваш код является прошивкой устройства. В этом случае вы, вероятно, захотите жестко контролировать зависимости (требуются очень конкретные версии). Это дает вам полный контроль над всей системой, что упрощает тестирование системы и может быть важным, если ваше устройство соответствует определенным требованиям безопасности, безопасности или надежности (например, это медицинское устройство или датчик, отправленный Плутону). В целом, если вы распространяете свой продукт в форме бинарного образа или образа файловой системы, вам, вероятно, захочется использовать фиксированные зависимости.
Если вы хотите, чтобы пользователи могли динамически связываться с любыми версиями зависимостей, которые поставляются с их системами (что полезно по многим причинам, включая обновления безопасности), то вы, вероятно, захотите ослабить требования. Уточните, какие версии поддерживаются, ограничьте себя документированными API, доступными в этих версиях, используйте инструмент для обеспечения выполнения требований (выведите ошибку, если зависимость слишком старая), и протестируйте свой код на как можно большем количестве версий зависимостей. ,
Как только вы поймете, насколько сильно вы хотите контролировать свои зависимости, вы можете выбрать механизм, которым они будут управляться. Вы можете использовать такой инструмент, как Apache Ivy для автоматической выборки зависимостей, GNU Autoconf для принудительного применения определенных версий, или вы можете вставить код в свой Git-репозиторий и собрать его самостоятельно. Конкретный выбор не так важен; Используйте все, что соответствует вашим требованиям и проще всего для вас и ваших пользователей.
Другие решения