Комментарии 17
module github.com/rumyantseva/hello
go 1.13
require github.com/sirupsen/logrus v1.4.2 // indirect
Ну штош, это уже гораздо больше похоже на рубевый Gemfile (и Gemfile.lock), значит верной дорогой идете! Еще лет пять эволюции…
А вообще шутки шутками, но почему файлы go.mod,go.sum не были названы в стандартном ключе типа Modfile и Modfile.lock? Опять какой то go-велосипед
В файле go.mod
. Если брать пример из статьи, то в строке
require github.com/sirupsen/logrus v1.4.2
вместо v1.4.2
можно подставить любую другую желаемую версию. После этого можно вызвать вручную go mod tidy
и go mod download
, чтобы обновить транзитивные зависимости и загрузить модули согласно этим обновлениям. Также можно просто перекомпилировать приложение (команды go mod
при этом будут вызваны автоматически).
Соотственно, если вы разрабатываете бибилиотеку и выкладываете ее, например, на Github, имеет смысл использовать семантическое версионирование с тегами вида v1.2.3
.
Если семантического версионирования нет, то версии будут выглядеть а ля v0.0.0-20190422165155-953cdadca894
(что-то вроде v0.0.0-дата-хэш
).
Или вот например, с тем же logrus
'ом: там сейчас есть коммиты в мастер, но тега v1.4.3
пока нет. И если посмотреть версии этой библиотеки на gocenter, помимо v1.4.2
там будут варианты а ля v1.4.3-0.20190807103436-de736cf91b92
.
Есть ещё вопрос.
В примере автоматически подставилась последняя версия. Получается что привязка будет именно к ней.
Есть ли какая-то возможность указать dev версию или master ветку?
Есть ли возможность указывать последнюю минорную или мажорную версию?
В приципе, в некотором роде можно, но тогда уже не в самом файле go.mod. Можно через go get указывать бранчи, но опять же автоматически go get
не будет следить за всеми обновлениями.
Тогда ваш процесс сборки приложения будет всегда из двух шагов состоять:
- Вызывать
go get github.com/sirupsen/logrus@master
— при этом файлgo.mod
обновится автоматически - Вызвать собственно компиляцию.
С мажорными версиями тоже отдельная история: мажорная версия должна быть указана в пути модуля.
Вроде без GOPATH нормально не работает расширение VS Code для работы с Go. Более того, проект должен быть внутри папки, куда указывает переменная, чтобы правильно подсвечивался синтаксис.
Тоже сталкивалась с проблемами с VS Code, да. Обещают, что если включить gopls
, то более или менее должно заработать. Но как-то gopls
у меня не прижился пока.
Классно написано, спасибо!
Если вы принципиально не используете Go Modules (например, в легаси-проекте)
Кстати, я стараюсь не использовать модули для open-source проектов – это стимулирует всегда держать ухо востро, чтобы они работали с последними версиями (через CI или пулл-реквесты "не билдится", гг). И вообще GOPATH это ️
При этом не хотелось бы создавать свой отдельный форк на github.
Примером такой ситуации может быть:
Когда нам нужно подменить этот внешний код не для своего собственного непосредственного использования, а для «обмана» другой внешней зависимости.
Вроде в документации на Go Modules написано как при сохранении того же пути к внешнему коду в import фактически подставлять свой исправленный код. Но до меня все никак не
дойдет как именно это сделать.
Не пробовала так делать, но первое, что приходит в голову — инструкция replace. Из документации мне кажется, что если в vendor-mode работать, то результат должен быть как раз такой, как вы описываете.
Правда ли, что GOPATH и GOROOT больше не нужны?