From: Sergey Matveev Date: Tue, 23 Feb 2021 16:29:47 +0000 (+0300) Subject: Go modules considered harmful X-Git-Url: http://www.git.stargrave.org/?a=commitdiff_plain;h=b446dc7d4194b215aa65d2ab8e5e6f1862232c71;p=stargrave-blog.git Go modules considered harmful 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 полностью идеально решает эту задачу, никаких проблем. И даже поудобнее. И даже никакого дополнительного инструментария не надо использовать. ---