С момента создания проекта у Go не было четкой концепции версий пакетов, но это меняется. Управление версиями является источником значительной сложности, особенно в больших базах кода, и потребовалось некоторое время, чтобы разработать подход, который хорошо работает в масштабе в достаточно большом разнообразии ситуаций, подходящих для предоставления всем пользователям Go.
Релиз Go 1.11 добавил новую экспериментальную поддержку для контроля версий пакетов в команду go, в виде модулей Go.
Независимо от фактической технологии управления пакетами, "go get" и больший набор инструментов Go обеспечивает изоляцию пакетов с разными путями импорта. Например, стандартные библиотеки html/template и text/template сосуществуют, хотя оба являются "package template". Это наблюдение приводит к некоторым советам для авторов пакетов и пользователей пакетов.
Пакеты, предназначенные для публичного использования, должны стараться поддерживать обратную совместимость по мере их развития. Рекомендации по совместимости с Go 1 - хороший справочник: не удаляйте экспортированные имена, поощряйте составные литералы с тегами и т.д. Если требуется другая функциональность, добавьте новое имя вместо изменения старого. Если требуется полный разрыв, создайте новый пакет с новым путем импорта.
Если вы используете поставляемый извне пакет и беспокоитесь о том, что он может измениться неожиданными способами, но еще не используете модули Go, самое простое решение - скопировать его в локальный репозиторий. Это тот подход, который Google использует для себя и поддерживается командой go с помощью метода, называемого "vendoring". Он включает в себя хранение копии зависимости по новому пути импорта, который идентифицирует ее как локальную копию.
Читайте также:
- Go FAQ: Почему "go get" использует HTTPS при клонировании репозитория?
- Как писать Go код (а также как организовать структуру своего кода)
- Эффективный Go
Комментариев нет:
Отправить комментарий