*** Phil Kulin [2016-11-15 15:30]: >А почему такая странная установка gogost? Почему нельзя сделать, чтобы >хотя бы откуда-то он ставился штатными методами самого Go? Это речь про go get? * они не позволяют зафиксировать/указать нужный коммит/тэг, насколько помню -- каждый вызов go get может скачать другую версию кода. Это не допустимо для детерминированных сборок * они не позволяют указать разные URL репозиториев. Задаётся только что-то одно, типа github.com/foo/bar. Если эта централизованная точка получения кода падает -- сборку провести нельзя, не поменяв go get аргументы. Хотя это можно решить Makefile-ами которые будут дёргать то одну команду, то другую * если появится какая-нибудь собираемая документация, типа Texinfo или Sphinx, то склонировав репозиторий, пользователь библиотеки не получает её в собранном в готовом виде. Заставлять его иметь у себя сборочную систему для документации я считаю не хорошо. То есть, во время релизов нужно как-то где-то предоставлять собранную документацию. Кроме того, если появляются зависимости от других програм, то наверняка это будет какой-то git submodule, но который ссылается тоже на какой-то один URL и он может лежать и просто склонировав gogost репозиторий и забыв сделать git submodule update -- человек не получит у себя на жёстком диске что-то целостное. То есть: исходный код разработчика это исходный код разработчика, а исходный код готовой библиотеки -- это уже другое. Иметь в репозитории полностью всю собранную документацию и копию всех зависимостей закоммиченную -- само собой отвратительно и не красиво * go get не предоставляет возможностей криптографической аутентификации скачанного кода. Управлять и "передавать" доверие в нём нельзя. Предоставляемые мной tarball-ы подписаны и доверие (.sig) может распространяться и дальше, без online-а или PKI какого-нибудь В общем это это гибче и надёжнее. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF