Комментарии 19
НЛО прилетело и опубликовало эту надпись здесь
Так как часть статьи посвящена конфигурации, от себя еще добавлю ссылку на статью Дейва Чейни. Смысл ее в том, что параметры конфигурации можно делать функциями, чтобы позволить пользователю библиотеки самому решать, какое поведение ему нужно в той или иной ситуации. Вот, например, использование этого подхода, в redigo, а вот пример из модуля net/http стандартной библиотеки.
+3
Я сторонник 'repeatable build', поэтому если для двух разных программ требуются разные версии одной зависимости, то GOPATH тут к сожалению никак не подходит. Я использую gb, как и автор статьи советует во многих местах, и тут начинаются проблемы… большие проблемы… Никакая IDE не умеет работать с вендорингом, всё захардкожено на GOPATH, все линтеры и чекеры бешено кричат что не найдены зависимости и т.д. Поэтому на данном этапе пока лучше придерживаться строгих конвенций Go, которые идут из коробки, либо придётся костылить, костылить и костылить.
+1
можно использовать разные GOPATH для разных проектов
у этого подхода есть конечно свои минусы, но все же имеет право на жизнь
у этого подхода есть конечно свои минусы, но все же имеет право на жизнь
0
Плагин для IntelliJ IDEA уже очень давно поддерживает несколько gopath и кастомные пути до библиотек. В том числе всё прекрасно работает с gb.
+1
go 1.6 умеет вендоринг ведь по-дефолту (до этого и 1.5 умел, но только с GO15VENDOREXPERIMENT=1). Раньше использовали gb, теперь дефолтный вендоринг.
+1
Оно, вроде как, требует чтобы сам проект находился внутри GOPATH и билдит в GOPATH/pkg и GOPATH/bin, а хотелось бы чтобы всё было внутри папки с проектом, как делает gb. Или я ошибаюсь?
0
Да нужно, но ведь это даже и удобно, держать все проекты в GOPATH. Но нет никаких проблем с использованием разных версии одной зависимости, да и проблем с линтерами и IDE нету.
А CI уже билдит все в докере, потому проблем и тут нету.
А CI уже билдит все в докере, потому проблем и тут нету.
0
Перешёл на ваш вариант, вместо 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 не сильно даёт уйти от дефолтов.
Что ещё раз подтверждает мои слова, что пока что Go не сильно даёт уйти от дефолтов.
+1
Специфические тулзы используете, у меня все просто — vim+vim-go+gocоde для автокомплита, еще :GoBuild, :GoTest и тд использую иногда, все работает. Насколько знаю, тот же gometalinter умеет vendor.
С go1.4-1.5 и gb были проблемы, особенно с эмаксом, писал сам костыли, потом просто забил на все это радуюсь.
С go1.4-1.5 и gb были проблемы, особенно с эмаксом, писал сам костыли, потом просто забил на все это радуюсь.
+1
как раз gometalinter использует gotype, с которым эти самые проблемы. Все остальные линтеры понимают, а самый нужный — нет. Я не сказал бы, что использую специфические тулзы: SublimeText, Go с нативным вендорингом, gotype из стандартной библиотеки Go через плагин к SublimeText. Ещё пытался использовать единственный плагин для go — GoSublime, но он категорически отказывается работать если проект не в GOPATH или вендорится как-то.
Вроде как всё вполне популярно и ничего специфичного, но не работает вместе.
Вроде как всё вполне популярно и ничего специфичного, но не работает вместе.
0
FiloSottile/gvt вендорит зависимости внутрь проекта. Так же можно указать версию зависимости.
gvt is a simple vendoring tool made for Go native vendoring (aka GO15VENDOREXPERIMENT), based on gb-vendor
gvt is a simple vendoring tool made for Go native vendoring (aka GO15VENDOREXPERIMENT), based on gb-vendor
+1
При использовании
GOPATH=/path/to/vendor:/path/to/mycode
такой проблемы нет.
Важно: vendor — должен быть первым каталогом, ваши исходники — после.
GOPATH=/path/to/vendor:/path/to/mycode
такой проблемы нет.
Важно: vendor — должен быть первым каталогом, ваши исходники — после.
-1
НЛО прилетело и опубликовало эту надпись здесь
Для вендоринга зависимостей лучше подходит утилита manul, которая использует git submodules, в таком случае проект не зависит от этой самой утилиты, а при операции go get go сам рекурсивно ставит зависимости:
0
Кое-какие практики спорны, я к примеру раньше часто сталкивался с «environment hell», когда для того чтобы заставить систему из нескольких программ заработать, нужно определить парочку «магических» переменных окружения. Особенно может доставить проблем постоянное изменение PATH, приводящее к путанице с несколькими совпадениями, которые «выстреливают». Так что для себя я всегда стараюсь фиксировать минимально необходимый PATH, а остальное вызывать по относительным/абсолютным путям. Кстати, npm решил эту проблему очень элегантно: npm run «script» запускает скрипт, прописанный в scripts у package.json.
Также я всегда использую свой GOPATH для каждого Go-проекта, так же как и virtualenv для каждого Python-проекта, ибо это единственный способ надежно проверять зависимости.
Также я всегда использую свой GOPATH для каждого Go-проекта, так же как и virtualenv для каждого Python-проекта, ибо это единственный способ надежно проверять зависимости.
0
Ещё одна проблема с GOPATH — это форк проектов на github. Решил ты помочь в разработке foo/bar, делаешь форк к себе moi/bar и клонируешь на локальную машину. И все, проект не собирается, поскольку в коде куча мест с import foo/bar/, ну и приходится либо делать симлинк, либо работать с двумя remote в git.
+3
gvt позволяет хакнуть систему и в файле манифеста для импорта прописать свой путь к репозиторию (к своему форку, например), при этом не меняя название и путь к папке с зависимостью. Апдейты и ресторы такой зависимости будут проходить из вашего репозитория, а все вокруг будут думать что это оригинальная зависимость.
0
На мой вкус рекомендации Герранда по именованию отвратительны. Easy to type как критерий? Код пишется один раз, читается — десятки. Длинные, но консистентные имена мешают понять использующий их код? Переписывайте код, значит, а не сокращайте идентификаторы до одной буквы.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Лучшие практики Go, шесть лет в деле