“Before software can be reusable, it first has to be usable.” – Ralph Johnson
Это статья скорее для себя, нежели чем хотелось чем-то поделиться. Идея её написания висела довольно давно, но сейчас сподвигло её написать статья “I want off Mr. Golang’s Wild Ride”. Мысленно можно разделить эту статью на две части: первая, в которой идёт обсуждение объединения или нормализации API между разными операционными системами, и вторая, в которой идёт речь про модули и их реализацию. Russ Cox на своём сайте сделал серию из 11 (!) статей, чтобы объяснить почему модули это не так просто, как казалось. Давайте кратко пройдёмся по истории работы с библиотеками в golang.
Ненавистный GOPATH
Первое, что тебе нужно было сделать прежде, чем начать работу с golang - это установить переменную GOPATH. Она была нужна для того, чтобы команда go get знала куда складывать пакеты. Сейчас есть значение по умолчанию равное $HOME/go, что немножко упрощает работу, но не сильно. В качестве неймспейса для всех библиотек используется формат host/namespace/lib, например: github.com/xo/usql.
Пробуем поставить утилиту usql:
% time go get github.com/xo/usql
56.93s user 6.39s system 85% cpu 1:13.98 total
% tree -d -L 3 ~/go/src
├── github.com
│ ├── alecthomas
│ │ ├── chroma
│ │ ├── kingpin
│ │ ├── template
│ │ └── units
│ ├── danwakefield
│ │ └── fnmatch
│ ├── denisenkom
│ │ └── go-mssqldb
│ ├── dlclark
│ │ └── regexp2
│ ├── gohxs
│ │ └── readline
│ ├── golang-sql
│ │ └── civil
│ ├── go-sql-driver
│ │ └── mysql
│ ├── lib
│ │ └── pq
│ ├── mattn
│ │ ├── go-isatty
│ │ ├── go-runewidth
│ │ └── go-sqlite3
│ ├── xo
│ │ ├── dburl
│ │ ├── tblfmt
│ │ ├── terminfo
│ │ ├── usql
│ │ └── xoutil
│ └── zaf
│ └── temp
└── golang.org
└── x
├── crypto
└── sys
% du -h --max-depth=1 ~/go/src/
77M ./github.com
35M ./golang.org
111M .
Утилита предназначена для работы с разными базами данных и ожидаемо ей требуется много библиотек-драйверов для работы, но 111 мегабайт и минута на скачивание выглядит, как перебор. Если вам нужна только сама утилита, всегда можно использовать опцию -u. В защиту такого подхода, хочу сказать что использование прямого соответствия между импортом библиотеки и пути по которому она находится удобно. Так как язык разработал Google, то сразу был сделан вывод о том, что вся эта система работала поверх монорепозитория внутри компании и такое использование было логично. Но как только язык вышел публично, сразу стало понятно что использовать хост сервиса в пути не самое удобное решение. В случае, если проект был перемещён в другое пространство, ничего страшного не происходит, но вот если поменялся хост, то труба. Об этом подумали несколько людей и началась вторая эпоха.
Средневековый vendor
Когда node.js только набирал популярность (версии 0.8-0.12), шёл довольно большой холивар на тему вендоринга зависимостей. Были люди, которые говорили, что нужно складывать всю папку node_modules в репозиторий и при обновлении комиттить изменения, но в итоге сообщество пришло к тому, что это приносит только лишние расходы и отказались. Как мы все потом знаем, это привело к трагедии Дарта Плегаса leftpad. В Golang решили пойти тем же путём и появилась папка vendor, правда чтобы её использовать необходимо было перезаписать GOPATH в текущую директорую и тогда начинались пляски с тем, что в директории должна была быть папка src, а в .gitignore шли директории bin/ и pkg/. Эту проблему надо было автоматизировать и появились инструменты, чтобы с таким подходом было работать удобно, а именно glider, а в последствии dep. Более того, dep был сделан как официальный эксперимент группы разработки языка, и в итоге именно он дал толчок развитию модулей в go 1.11. Из-за данных инструментов в репозиториях пропали папки vendor, так как они создавали lock-файлы и можно было воспроизвести среду. А вот проблемы были в том, что каждый инструмент делал свой формат. :(
Современный go.mod
И здесь мы возвращаемся к модулям с которых началась эта статья. В go 1.11 можно было с помощью переменной GO111MODULE=on, а с недавним релизом go 1.14 данное поведение стало по умолчанию. Что нужно сделать для того, чтобы его использовать прекрасно описано в The Go Blog в 4 (!) частях. Здесь бы хотелось сосредоточиться на том, почему это не современная штука.
Проблема №1. Перейти надо всем
Разработчики golang молодцы, что дали 3 минорные версии для того, чтобы авторы библиотек могли перейти на go.mod и судя по тому, что из 21000 открытых issues на гитхабе закрыто 18000 все были нацелены на использование данного инструмента.
Проблема №2. Формат mod в go.mod
Долго бомбило после прочтения PEP 518, что выбрали формат toml. Главное, что его выбрали потому что json слишком вербозный, а yaml имеет слишком сложную спецификацию. В golang решили просто пойти своим путём и сделать формат, который надо парсить. Можете пойти почитать, как он устроен тут. Уверен, что выбор был сделан исходя из принципа упрощения: зачем брать известное, если можно сделать своё простое? Более того, этот файл нельзя трогать руками. Всё взаимодействие с ним идёт через команду go get, так что частично мы откатились к прежнему решению с GOPATH, просто теперь все пакеты лежат в GOPATH/pkg.
Проблема №3. Версионирование
Все мы оказывались в ситуации, когда автор библиотеки не удосужился указать версии своих зависимостей и занимаешься бинарным поиском совместимых пакетов. В golang решили пойти дальше и сказать, что изменение мажорной версии должно приводить к изменении путей. Тема хорошая, но реализация полагается на рациональность людей, который будут эту мажорную версию менять. А как мы знаем, у этой проблему есть две крайности: Chrome,который имеет 80 версию на данный момент, и PostgresQL, который долгое время жил на 9.x номенклатуре и утверждал, что вторая цифра - это тоже мажорный релиз. Справился ли подход golang с тем, чтобы пакеты всегда собирались при обновлении пакетов? Нет, для примера вы можете взять обновление пакета grpc-consul-resolver из-за того, что в минорной версии сменился интерфейс, и это библиотека от google.
Проблема №4. Настройки
Ладно, тут я просто напишу GOSUMDB=off, GOPRIVATE=*example.com* и обязательно GO111MODULE=on.
Итого
Немножко грустно от того, что в мире уже десяток популярных языков программирования, а понятной и простой системы по работе с пакетами так до сих пор и изобретают с нуля.
P.s. а может быть и не с нуля, но осадочек остался.
P.p.s. кстати, с модулями не отказались от вендоринга, даже комманду сделали для этого go mod vendor.