Pull to refresh

Comments 7

А что делать писателям модулей на Go которые используют дргую систему управления версиями отличной от Git, Mercury и тд?
На сколько я понял go.mod заточен только под определенные системы управления версиями.

Не совсем так. go.mod вообще ни на что не заточен, в нём просто указываются версии в формате semver, а откуда они взялись — без разницы. На git/github/etc. заточен скорее go get, который их скачивает — но он умеет выкачивать модули и как обычные архивы по http, главное чтобы в именах файлов/каталогов были те же версии в формате semver. Таким образом, если выкладывать модули в виде таких файлов-архивов, то без разницы, как именно они разрабатываются — можно вообще не использовать системы контроля версий вроде git.

UFO just landed and posted this here
документация по модулям Go кажется как-то излишне сложной, абстрактной.

Это во многом потому, что описывается новый подход, который до этого не использовался в других языках. К нему ещё не привыкли, хуже того, он отличается от того, к чему привыкли, у него свои особенности, плюс его работоспособность и эффективность попытались доказать математикой. Со временем всё это пройдёт.

UFO just landed and posted this here

Статья действительно годичной давности и про vgo, но она (а точнее цикл статей) ценна тем, что описывает почему модули были реализованы именно таким образом. Текущая реализация модулей от описанной в этом цикле статей отличается незначительно — просто были учтены некоторые нюансы, которые всплыли при коллективном обсуждении и экспериментах с vgo.


Спецификация модулей не является сложной, проблема с адаптацией существующих инструментов для поддержки модулей в другом: изменилась идеология. Например, раньше gorename переименовывал идентификаторы любых пакетов, а не только текущего, благодаря тому, что он находил эти пакеты в GOPATH — а с модулями возможности переименовать что-то в сторонней библиотеке нет физически, потому что эта библиотека теперь лежит в виде неизменяемого zip-архива. Поэтому адаптация инструментов под модули требует переосмысления их логики и функционала, что и замедляет процесс.


Что касается новизны подхода, то в нём есть несколько критичных отличий от всех известных на данный момент решений:


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

P.S. Я Goland не использую, но, действительно, везде написано, что поддержка модулей там есть, причём полная и уже больше полугода, так что должно работать.

UFO just landed and posted this here
Sign up to leave a comment.

Articles