ЯжПрограммист.com

Нужен совет, какие инструменты и практики лучше использовать для управления зависимостями в крупных проектах? Какие подводные камни могут возникнуть при работе с ними? Предложили: Go Modules и vendoring. Что скажете по ним?

Go Modules - это официальный инструмент для управления зависимостями в Go, начиная с версии 1.11 если не ошибаюсь. Он автоматически управляет версиями зависимостей и поддерживает семантическое версионирование. Vendoring, с другой стороны, предполагает копирование всех зависимостей в папку vendor, что дает полный контроль над ними, но увеличивает размер репозитория. Какой из подходов тебе подходит больше?

Пока склоняюсь к Go Modules, но не уверен, насколько он подходит для крупных проектов. Какие-то преимущества у него перед vendoring? Их можно выделить?

Go Modules упрощает управление зависимостями. Он автоматически разрешает конфликты версий и позволяет легко обновлять зависимости. А еще он интегрируется с репозиториями, такими как GitHub, что упрощает работу с внешними библиотеками. Vendoring, напротив, требует ручного управления зависимостями, что может быть трудоемким в крупных проектах.

А какие подводные камни есть у Go Modules? Я слышал, что могут быть проблемы с воспроизводимостью сборки. Это реально так? Или проблемы могут возникть только в индивидуальных случаях?

Кирилл, да, это возможно, если не использовать go.sum правильно. Файл go.sum содержит хэши зависимостей, что обеспечивает воспроизводимость сборки. Но, если его игнорировать или неправильно обновлять, могут возникнуть проблемы,других случае я не знаю. Также важно следить за версиями зависимостей, чтобы избежать конфликтов.

Я тут не могу понять, а как быть с безопасностью? Могут ли устаревшие зависимости стать проблемой? Не сидеть жее и нее провеерять постоянно обновления.

Конечно. Устаревшие зависимости могут содержать уязвимости. Go Modules позволяет легко обновлять зависимости, но важно регулярно проверять их на наличие уязвимостей. Для этого можно использовать инструменты, такие как dependabot или gosec.

А что насчет vendoring? Какие преимущества он дает в крупных проектах? Есть опыт? Я его пока только изучаю детально. И думаю,может попробовать стоит..

Не плохой выбор! Vendoring полезен, если тебе нужен полный контроль над зависимостями. Это особенно важно в изолированных средах, где доступ к внешним репозиториям ограничен. Но он увеличивает размер репозитория и усложняет обновление зависимостей. Это нужно знать.

А как быть с конфликтами версий в vendoring? Это реальная проблема? Можно ее как-то обойти? Иесли да,  то что для этого можно сделать?

Да, это одна из главных проблем vendoring. Если две зависимости требуют разных версий одной библиотеки, это может привести к конфликтам. В Go Modules такие конфликты разрешаются автоматически, но в vendoring тебе придется решать их вручную. А значит нужен опыт.

И как же тогда быть? А как ты советуешь комбинировать эти подходы? Например, использовать Go Modules для разработки, а vendoring для production?

Это хорошая идея. Go Modules можно использовать для разработки, чтобы упростить управление зависимостями, а vendoring — для production, чтобы обеспечить стабильность и независимость от внешних репозиториев. Например, можно использовать команду go mod vendor для создания папки vendor перед сборкой.

А как быть с зависимостями, которые часто обновляются? Например, если я использую библиотеку, которая активно развивается.