Go modules considered harmful

Что: b446dc7d4194b215aa65d2ab8e5e6f1862232c71

Когда: 2021-02-23 19:29:47+03:00

Темы: go hate

https://www.devever.net/~hl/gomod
Автор то конечно вправе считать как угодно, но я кардинально против его
мнения, как и он кардинально против мнения авторов Go:

авторы хотят чтобы зависимости в Go прибивались прям жёстко к чётко

заданной версии. И я полностью поддерживаю это! Я хочу
детерминированности в поведении. Автор считает что нужно использовать
семантическое версионирование, но использовать самую последнюю версию
в пределах совместимости. Потеря детерминированности сборки -- ничто
не может оправдать. А люди всегда остаются людьми и всё равно рано или
поздно будут косяки с семантическими версиями

автор считает что для повторяемой сборки, для детерминированности

можно и нужно использовать GOPATH просто навсего. Отчасти согласен.
Точнее я полностью согласен. Но... если нужную версию можно не
обязательно полностью закоммитить, а указать через хэш в go.mod, то в
чём проблема? Более того, в чём проблема закоммитить всё что хочешь в
vendor директорию?

у меня стойкое ощущение что автор не до конца понял как работать с

модулями. GOPATH deprecation нисколько не убирает возможность гвоздями
прибитые версии софта использовать и коммитить рядом, класть через
submodule или как угодно ещё

автор много пишет про то, что он не хочет видеть несколько версий

одной и той же библиотеки у себя в программе. Согласен -- неприятно. А
что делать? Я так и не увидел его предложение что делать со случаем
когда A зависит от B версии vX, а C зависит от B версии vY. Хотя он
упоминает семантическое версионирование gopkg.in-style... которое
идентично must-have-to-use семантическому версионированию в модулях.
Автор, так ты прочь или не прочь использовать несколько версий
библиотеки? С модулями все возможности остаются. А вот в Python
действительно подобную ситуацию вообще никак не разрешить из коробки

автор считает что из-за жёстко привязанных версий у package maintainer

нет средств использовать немного другие версии. Я считаю это хорошо --
детерминированность это хорошо, и всегда лучше её отсутствия. А если
кому очень надо что-то поменять -- go ahead и делай правки, накладывай
патчи, как это было всю жизнь всегда

всё что автор написал касательно централизации распространения модулей

-- бред. По мне, так это буквально точно такое же популярное мнение
что git это значит использовать Github. В Go можно запускать свои
proxy, вообще их не использовать, делать replace внутри go.mod --
средств огромная масса чтобы делать всё что угодно и как угодно. Лично
я вообще не привлекаю нигде инфраструктуру Google при работе с Go

такое ощущение, что куча хотелок автора решается replace в go.mod,

что не возбраняется и не запрещается

Я отчасти во многом похож с автором: я активно использовал GOPATH для
предоставления зависимостей в проект. Признаюсь, впервые когда я увидел
GOPATH deprecation, то подумал что как теперь быть то? Как теперь
предоставлять в едином tarball-е всё что нужно? Копнув глубже, понимаешь
что vendoring полностью идеально решает эту задачу, никаких проблем. И
даже поудобнее. И даже никакого дополнительного инструментария не надо
использовать.

оставить комментарий

Сгенерирован: SGBlog 0.34.0