Комментарии 7
А что делать писателям модулей на Go которые используют дргую систему управления версиями отличной от Git, Mercury и тд?
На сколько я понял go.mod заточен только под определенные системы управления версиями.
Не совсем так. go.mod вообще ни на что не заточен, в нём просто указываются версии в формате semver, а откуда они взялись — без разницы. На git/github/etc. заточен скорее go get
, который их скачивает — но он умеет выкачивать модули и как обычные архивы по http, главное чтобы в именах файлов/каталогов были те же версии в формате semver. Таким образом, если выкладывать модули в виде таких файлов-архивов, то без разницы, как именно они разрабатываются — можно вообще не использовать системы контроля версий вроде git.
документация по модулям Go кажется как-то излишне сложной, абстрактной.
Это во многом потому, что описывается новый подход, который до этого не использовался в других языках. К нему ещё не привыкли, хуже того, он отличается от того, к чему привыкли, у него свои особенности, плюс его работоспособность и эффективность попытались доказать математикой. Со временем всё это пройдёт.
Статья действительно годичной давности и про vgo, но она (а точнее цикл статей) ценна тем, что описывает почему модули были реализованы именно таким образом. Текущая реализация модулей от описанной в этом цикле статей отличается незначительно — просто были учтены некоторые нюансы, которые всплыли при коллективном обсуждении и экспериментах с vgo.
Спецификация модулей не является сложной, проблема с адаптацией существующих инструментов для поддержки модулей в другом: изменилась идеология. Например, раньше gorename переименовывал идентификаторы любых пакетов, а не только текущего, благодаря тому, что он находил эти пакеты в GOPATH — а с модулями возможности переименовать что-то в сторонней библиотеке нет физически, потому что эта библиотека теперь лежит в виде неизменяемого zip-архива. Поэтому адаптация инструментов под модули требует переосмысления их логики и функционала, что и замедляет процесс.
Что касается новизны подхода, то в нём есть несколько критичных отличий от всех известных на данный момент решений:
- всегда используется минимально возможная версия всех зависимостей
- требуется использовать semver для версионирования всех модулей
- требуется вечная совместимость будущих версий модуля (если API модуля изменяется несовместимым образом то модуль необходимо переименовать)
- библиотеки не имеют возможности контролировать зависимости использующего их приложения, помимо указания минимальных версий зависимостей библиотек (т.е. библиотека не может кому-то заблокировать использование "неподходящих" версий своих зависимостей если они больше минимально необходимой)
- приложение может содержать несколько версий одной библиотеки, при условии, что у них отличается мажорный номер версии (т.е. у них несовместимые API)
P.S. Я Goland не использую, но, действительно, везде написано, что поддержка модулей там есть, причём полная и уже больше полугода, так что должно работать.
Go += управление версиями пакетов