From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 Date: Wed, 20 Feb 2019 22:17:03 +0100 From: Alexey Gladkov To: ALT Linux Team development discussions Message-ID: <20190220211703.GD2364@MacBook-PC.fortress> References: <20190122111233.GE11968@Legion-PC.fortress> <20190122111640.GB30125@altlinux.org> <20190122145508.GA21546@dad.imath.kiev.ua> <20190205174908.GB21346@altlinux.org> <20190205205825.GA20622@dad.imath.kiev.ua> <20190206001736.GA26716@altlinux.org> <20190219170340.GA8634@altlinux.org> <20190219170832.GO4140@comp-core-i7-2640m-0182e6> <20190220101221.GA28897@amox.t-linux.by> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190220101221.GA28897@amox.t-linux.by> Subject: Re: [devel] [#219699] DONE (try 2) del=golang-tools X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 21:17:08 -0000 Archived-At: List-Archive: List-Post: 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