Лучшие практики Go, шесть лет в деле

[FZambia]

Так как часть статьи посвящена конфигурации, от себя еще добавлю ссылку на статью Дейва Чейни. Смысл ее в том, что параметры конфигурации можно делать функциями, чтобы позволить пользователю библиотеки самому решать, какое поведение ему нужно в той или иной ситуации. Вот, например, использование этого подхода, в redigo, а вот пример из модуля net/http стандартной библиотеки.

[evnuh]

Я сторонник 'repeatable build', поэтому если для двух разных программ требуются разные версии одной зависимости, то GOPATH тут к сожалению никак не подходит. Я использую gb, как и автор статьи советует во многих местах, и тут начинаются проблемы… большие проблемы… Никакая IDE не умеет работать с вендорингом, всё захардкожено на GOPATH, все линтеры и чекеры бешено кричат что не найдены зависимости и т.д. Поэтому на данном этапе пока лучше придерживаться строгих конвенций Go, которые идут из коробки, либо придётся костылить, костылить и костылить.

[ramzes_yan]

можно использовать разные GOPATH для разных проектов
у этого подхода есть конечно свои минусы, но все же имеет право на жизнь

[ZurgInq]

Плагин для IntelliJ IDEA уже очень давно поддерживает несколько gopath и кастомные пути до библиотек. В том числе всё прекрасно работает с gb.

[Edison]

go 1.6 умеет вендоринг ведь по-дефолту (до этого и 1.5 умел, но только с GO15VENDOREXPERIMENT=1). Раньше использовали gb, теперь дефолтный вендоринг.

[evnuh]

Оно, вроде как, требует чтобы сам проект находился внутри GOPATH и билдит в GOPATH/pkg и GOPATH/bin, а хотелось бы чтобы всё было внутри папки с проектом, как делает gb. Или я ошибаюсь?

[Edison]

Да нужно, но ведь это даже и удобно, держать все проекты в GOPATH. Но нет никаких проблем с использованием разных версии одной зависимости, да и проблем с линтерами и IDE нету.
А CI уже билдит все в докере, потому проблем и тут нету.

[evnuh]

Перешёл на ваш вариант, вместо gb использую стандартный вендоринг + gvt. Настроил билд как обычный go build, без инсталла, поэтому структура проектов почти не менялась (никаких pkg и bin с кучей бинарных файлов не появилось). Да вот только беда, основной linter gotype так и не завёлся, т.к. 1) он не понимает вендоринг из коробки (есть хак, который естественно не работает в IDE) и он требует установленных пакетов в GOPATH (go build -i спасает, но ломает мою красивую иерархию папок). Собственно, линтеры в IDE так и не работают в случае даже с нативным вендорингом. На gotype повесили Milestone чтобы он смотрел в src а не в pkg на версию 1.7 — 1.8, поэтому ждём. Радует что все остальные тулзы заработали, которые в случае с gb не понимали где что искать.
Что ещё раз подтверждает мои слова, что пока что Go не сильно даёт уйти от дефолтов.

[Edison]

Специфические тулзы используете, у меня все просто — vim+vim-go+gocоde для автокомплита, еще :GoBuild, :GoTest и тд использую иногда, все работает. Насколько знаю, тот же gometalinter умеет vendor.
С go1.4-1.5 и gb были проблемы, особенно с эмаксом, писал сам костыли, потом просто забил на все это радуюсь.

[evnuh]

как раз gometalinter использует gotype, с которым эти самые проблемы. Все остальные линтеры понимают, а самый нужный — нет. Я не сказал бы, что использую специфические тулзы: SublimeText, Go с нативным вендорингом, gotype из стандартной библиотеки Go через плагин к SublimeText. Ещё пытался использовать единственный плагин для go — GoSublime, но он категорически отказывается работать если проект не в GOPATH или вендорится как-то.
Вроде как всё вполне популярно и ничего специфичного, но не работает вместе.

[Rbatukaev]

FiloSottile/gvt вендорит зависимости внутрь проекта. Так же можно указать версию зависимости.

gvt is a simple vendoring tool made for Go native vendoring (aka GO15VENDOREXPERIMENT), based on gb-vendor

[spotifi]

При использовании
GOPATH=/path/to/vendor:/path/to/mycode
такой проблемы нет.
Важно: vendor — должен быть первым каталогом, ваши исходники — после.

[TBoolean]

Для вендоринга зависимостей лучше подходит утилита manul, которая использует git submodules, в таком случае проект не зависит от этой самой утилиты, а при операции go get go сам рекурсивно ставит зависимости:

[markhor]

Кое-какие практики спорны, я к примеру раньше часто сталкивался с «environment hell», когда для того чтобы заставить систему из нескольких программ заработать, нужно определить парочку «магических» переменных окружения. Особенно может доставить проблем постоянное изменение PATH, приводящее к путанице с несколькими совпадениями, которые «выстреливают». Так что для себя я всегда стараюсь фиксировать минимально необходимый PATH, а остальное вызывать по относительным/абсолютным путям. Кстати, npm решил эту проблему очень элегантно: npm run «script» запускает скрипт, прописанный в scripts у package.json.

Также я всегда использую свой GOPATH для каждого Go-проекта, так же как и virtualenv для каждого Python-проекта, ибо это единственный способ надежно проверять зависимости.

[acmnu]

Ещё одна проблема с GOPATH — это форк проектов на github. Решил ты помочь в разработке foo/bar, делаешь форк к себе moi/bar и клонируешь на локальную машину. И все, проект не собирается, поскольку в коде куча мест с import foo/bar/, ну и приходится либо делать симлинк, либо работать с двумя remote в git.

[evnuh]

gvt позволяет хакнуть систему и в файле манифеста для импорта прописать свой путь к репозиторию (к своему форку, например), при этом не меняя название и путь к папке с зависимостью. Апдейты и ресторы такой зависимости будут проходить из вашего репозитория, а все вокруг будут думать что это оригинальная зависимость.

[Cromathaar]

На мой вкус рекомендации Герранда по именованию отвратительны. Easy to type как критерий? Код пишется один раз, читается — десятки. Длинные, но консистентные имена мешают понять использующий их код? Переписывайте код, значит, а не сокращайте идентификаторы до одной буквы.