Re: [devel] [#219699] DONE (try 2) del=golang-tools

[Alexey Gladkov <legion@altlinux.ru>]

On Wed, Feb 20, 2019 at 01:12:21PM +0300, Denis Pynkin wrote:
> > Гораздо правильнее будет завендорить их, а эти пакеты удалить.
> 
> Так у нас появилось уже внятное полиси про пакетирование Golang?

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

Их секретное кунг-фу было поддержка обратной совместимости в master до
самой первой версии и если что-то ломаешь, то делать новый модуль.

Но спустя несколько лет к апстриму пришло осознание, что поддерживать
обратную совместимость и переименовывать модули не работает даже внутри
гугла. Разработчик может даже удалить модуль с github.com и тем самым
сломать других. Поэтому им пришлось ввести vendor директории, где можно
сохранить копию кода зависимостей. Но гугл не был бы гуглом если бы не
пошёл своим путём. Они не сделали сохранения ни какой информации о том,
что лежит в vendor. Там просто код. Поэтому появилось множество сторонних
проектов, которые сохраняли инфу о версиях и обновляли копию кода (godep,
glide, gpm, dep, vndr и т.д.).

Учитывая всё сказанное выше в тот момент, когда я начал паковать golang
было вроде логично сделать скрипты и макросы, чтобы упростить упаковку
исходников в общее дерево и обновлять их и проверять по зависимостям rpm
кто от модуля зависит.

Оглядываясь назад я считаю, что это было ошибкой.

Сейчас в golang осознали, что версии всё-таки нужны. В golang 1.11
создадут модули с semver, но с своими особенностями. Будет поддержка
vendor директории. Для интересующихся:

https://github.com/golang/go/wiki/Modules

После работы с довольно большими проектами на golang я сейчас считаю, что 
класть зависимости в vendor директорию единственный способ как
поддерживать проекты на golang. Если не просто класть код руками туда, а
использовать go.mod или godep, то понять кто с чем собран становится
достаточно просто.

Модули в пакетах всё равно не дают выигрыша так как после обновления
модуля нужно пересобрать всех конечных потребителей (цепочка зависимостей
может быть длинной).

> Лично я бы с удовольствием выкинул бы те 30+ пакетов-зависимостей,
> которые пришлось вливать ради LXD.
> 
> Можно ли глянуть на какой-нибудь пакет, где используется вендоринг?

http://git.altlinux.org/gears/m/md2man.git

или вот апстримные проекты:

https://github.com/docker/distribution
https://github.com/kubernetes/kubernetes
https://github.com/etcd-io/etcd

-- 
Rgrds, legion