Показаны сообщения с ярлыком Команды Go. Показать все сообщения
Показаны сообщения с ярлыком Команды Go. Показать все сообщения

воскресенье, 21 июля 2019 г.

Команды в Golang

В этом посте представлена подборка статей описывающих использование команд Go либо справочные статьи, выдаваемые командами Go.

  1. Команды Go: введение
  2. Инструмент go, команды
  3. Команды go: go build, компиляция пакетов и зависимостей
  4. Команды go: go clean, удаление объектных файлов и кэшированных файлов
  5. Команды go: go doc, показать документацию для пакета или символа
  6. Команды go: go env, напечатать информацию о среде окружения Go
  7. Команды go: go fix, обновить пакеты, чтобы использовать новые API
  8. Команды go: go fmt, gofmt (переформатировать) источники (исходные файлы) пакетов
  9. Команды go: go generate, генерация Go файлов посредством обработки источника
  10. Команды go: go get, загрузка и установка пакетов и зависимостей
  11. Команды go: go install, компиляция и установка пакетов и зависимостей
  12. Команды go: go list, вывод списка пакетов или модулей
  13. Команды go: go mod, обслуживание модуля
  14. Команды go: go mod download, загрузка модулей в локальный кеш
  15. Команды go: go mod edit, редактирование go.mod из инструментов или скриптов
  16. Команды go: go mod graph, распечатать граф требований модуля
  17. Команды go: go mod init, инициализировать новый модуль в текущем каталоге
  18. Команды go: go mod tidy, добавить отсутствующие и удалить неиспользуемые модули
  19. Команды go: go mod vendor, сделать вендорную копию зависимостей
  20. Команды go: go mod verify, проверка достоверности зависимостей
  21. Команды go: go mod why, объяснение необходимости пакета или модуля
  22. Команды go: go run, скомпилировать и запустить Go программу
  23. Команды go: go test, тестировать пакеты
  24. Команды go: go tool, запустить указанный инструмент go
  25. Команды go: go version, напечатать версию Go
  26. Команды go: go vet, сообщить о возможных ошибках в пакетах
  27. Вспомогательные темы инструмента go: режимы сборки
  28. Вспомогательные темы инструмента go: вызовы между Go и C
  29. Вспомогательные темы инструмента go: кеширование сборки и тестирования
  30. Вспомогательные темы инструмента go: переменные среды окружения
  31. Вспомогательные темы инструмента go: типы файлов
  32. Вспомогательные темы инструмента go: файл go.mod
  33. Вспомогательные темы инструмента go: переменная среды GOPATH
  34. Установка переменной среды GOPATH
  35. GOPATH и модули в Golang, внутренние каталоги
  36. Каталоги поставщиков (Vendor Directories) в Golang
  37. Вспомогательные темы инструмента go: протокол прокси модуля
  38. Вспомогательные темы инструмента go: пути импорта
  39. Пути удаленного импорта в Golang
  40. Проверка пути импорта в Golang
  41. Вспомогательные темы инструмента go: модули
  42. Определение модуля, файл go.mod
  43. Основной модуль и список сборки в Golang
  44. Поддержка требований модуля в Golang
  45. Псевдо-версии модулей в Golang
  46. Запросы модулей (module query) в Golang
  47. Совместимость модулей и семантическое управление версиями в Golang
  48. Загрузка и проверка модуля в Golang
  49. Модули и вендоринг в Golang
  50. Команда go get в режиме с поддержкой модулей
  51. Списки пакетов и шаблоны в Golang
  52. Флаги тестирования в Golang
  53. Функции тестирования в Golang
  54. Команда cover в Golang
  55. Команда cgo, использование cgo с командой go
  56. Команда cgo: ссылки Go к C
  57. Команда cgo: ссылки C к Go
  58. Команда cgo: передача указателей
  59. Команда cgo: особые случаи
  60. Использование команды cgo напрямую
  61. Команда fix в Golang
  62. Команда gofmt в Golang
  63. Команда vet в Golang
  64. Команда godoc в Golang


купить игрушку gopher

пятница, 19 июля 2019 г.

Команда godoc в Golang

godoc извлекает и генерирует документацию для программ Go.

Он работает как веб-сервер и представляет документацию как веб-страницу.

godoc -http=:6060

Использование:

godoc [flag]

Флаги:

-v
    режим с подробным выводом

-timestamps=true
    показать временные метки (timestamps) 
    со списком каталогов

-index
    включить идентификатор и индекс 
    полнотекстового поиска (окно поиска не отображается, 
    если -index не установлен)

-index_files=""
    шаблон glob с указанием индексных файлов; 
    если не пустой, индекс читается из этих файлов 
    в отсортированном порядке

-index_throttle=0.75
    значение указателя дроссельной заслонки; 
    значение 0 означает, что время не выделяется
    для индексатора (индексатор никогда не завершится), 
    значение 1,0 означает, что создание индекса 
    выполняется с полной скоростью (другим goroutines 
    может не хватить времени, пока индекс строится)

-index_interval=0
    интервал индексации; значение 0 устанавливает 5 минут,
    отрицательные значения индексов - 
    только один раз при запуске

-play=false
    включить песочницу

-links=true
    связать идентификаторы с их объявлениями

-write_index=false
    записать индекс в файл; 
    имя файла должно быть указано с
    -index_files

-maxresults=10000
    показано максимальное количество результатов 
    полнотекстового поиска (полнотекстовый индекс 
    не создается, если maxresults <= 0)

-notes="BUG"
    маркеры соответствия регулярного выражения, 
    чтобы показать (например, "BUG|TODO", ".*")

-goroot=$GOROOT
    Go корневой каталог

-http=addr
    адрес HTTP сервиса 
    (например, '127.0.0.1:6060' или просто ':6060')

-analysis=type,pointer
    разделенный запятыми список анализов для выполнения
    "type": отображать разрешение идентификатора, 
            информацию о типе, наборы методов,
            'implements' и статические вызываемые
    "pointer": отображать одноранговые каналы, 
               вызывающие и динамические абоненты канала
               (значительно медленнее)

-templates=""
    каталог, содержащий альтернативные файлы шаблонов;
    если установлено, каталог может содержать 
    альтернативные файлы шаблонов
    для файлов в $GOROOT/lib/godoc

-url=path
    вывести на стандартный вывод данные, 
    которые будут выдаваться
    HTTP запросом для указанного пути (path)

-zip=""
    zip-файл, предоставляющий файловую систему 
    для обслуживания; отключено, если пусто

По умолчанию godoc просматривает пакеты, которые находит через $GOROOT и $GOPATH (если установлены). Это поведение можно изменить, указав альтернативный $GOROOT с флагом -goroot.

Когда установлен флаг -index, индекс поиска сохраняется. Индекс создается при запуске.

Индекс содержит информацию как по идентификатору, так и по полнотекстовому поиску (поиск по регулярным выражениям) Максимальное количество отображаемых результатов полнотекстового поиска можно установить с помощью флага -maxresults; если установлено значение 0, полнотекстовые результаты не отображаются, и создается только индекс идентификатора, но не создается индекс полнотекстового поиска.

По умолчанию godoc использует системные GOOS/GOARCH. Вы можете указать параметры URL "GOOS" и "GOARCH", чтобы настроить вывод на веб-странице целевой системы.

Режим представления веб-страниц, обслуживаемых godoc, можно контролировать с помощью URL параметра "m"; в качестве значения он принимает список имен флагов через запятую:

all     показывать документацию для всех объявлений, 
        а не только экспортируемых

methods показывать все встроенные методы, а не только те, 
        которые не были экспортированы анонимными полями

src     показывать исходный код, 
        а не извлеченную документацию

flat    представить плоский (без отступа) 
        список каталогов с использованием полных путей

Например, https://golang.org/pkg/math/big/?m=all показывает документацию для всех (не только экспортируемых) объявлений пакета big.

По умолчанию godoc обслуживает файлы из файловой системы базовой ОС. Вместо этого .zip-файл может быть предоставлен с помощью флага -zip, который содержит файловую систему для обслуживания. Пути к файлам, хранящиеся в .zip-файле, должны использовать косую черту ('/') в качестве разделителя пути; и они должны быть без корней. Для $GOROOT (или -goroot) должен быть указан путь к каталогу файла .zip, содержащий корневой каталог Go. Например, для файла .zip, созданного командой:

zip -r go.zip $HOME/go

можно запустить godoc следующим образом:

godoc -http=:6060 -zip=go.zip -goroot=$HOME/go

Документация godoc конвертируется в HTML или в текст с использованием пакета go/doc. Godoc также показывает пример кода, который запускается пакетом тестирования


Читайте также:


четверг, 18 июля 2019 г.

Команда vet в Golang

vet проверяет исходный код Go и сообщает о подозрительных конструкциях, таких как вызовы Printf, аргументы которых не совпадают с форматом строки. vet использует эвристику, которая не гарантирует, что все отчеты являются подлинными проблемами, но он может найти ошибки, не обнаруженные компиляторами.

Vet обычно вызывается с помощью команды go. Эта команда проверяет пакет в текущем каталоге:

go vet

тогда как следующий пример проверяет пакеты, путь которых указан:

go vet my/project/...

Используйте go help packages, чтобы увидеть другие способы указания, какие пакеты проверять.

Код выхода vet не равен нулю для ошибочного вызова инструмента или, если возникла проблема, и 0 в противном случае. Обратите внимание, что инструмент проверяет не все возможные проблемы и зависит от ненадежной эвристики, поэтому его следует использовать только в качестве руководства, а не в качестве надежного индикатора правильности программы.

Чтобы просмотреть список доступных проверок, запустите "go tool vet help":

asmdecl      сообщить несоответствия между сборочными 
             файлами (assembly files) и Go декларациями

assign       проверить на бесполезные назначения

atomic       проверить на общие ошибки 
             используемые в sync/atomic пакете

bools        проверить на общие ошибки 
             затрагивающие булевы (boolean) операторы

buildtag     проверить что +build теги 
             правильно сформированы и корректно размещены

cgocall      выявить некоторые из нарушений 
             правил передачи cgo указателей

composites   проверить на композитные литералы без ключей 
             (unkeyed composite literals)

copylocks    проверить на locks 
             ошибочно переданные по значению

httpresponse проверить на ошибки использования HTTP ответов

loopclosure  проверить запросы на прохождение циклом 
             по переменным из вложенных функций

lostcancel   проверить cancel функции 
             возвращенные context.WithCancel при вызове

nilfunc      проверить на бесполезные сравнения 
             между функциями и nil

printf       проверить соответствие 
             строк и аргументов формата Printf

shift        проверить на сдвиги которые равны 
             или превосходят ширину целых чисел

stdmethods   проверить сигнатуры методов 
             хорошо известных интерфейсов

structtag    проверить что теги полей структур 
             соответствуют reflect.StructTag.Get

tests        проверить на общие ошибочные 
             использования тестов и примеров

unmarshal    сообщить о передаче unmarshal значений 
             не-указателей или не-интерфейсов 

unreachable  проверить на наличие недостижимого кода

unsafeptr    проверить на невалидные преобразования 
             uintptr в unsafe.Pointer

unusedresult проверить на неиспользуемые результаты 
             вызовов некоторых функций

Для получения подробной информации и флагов конкретной проверки, например printf, запустите "go tool vet help printf".

По умолчанию все проверки выполняются. Если для каких-либо флагов явно задано значение true, запускаются только эти тесты. И наоборот, если какой-либо флаг явно установлен в false, только эти тесты отключаются. Таким образом -printf=true запускает проверку printf, а -printf=false запускает все проверки, кроме проверки printf.

Основные флаги:

-c=N
    отображать проблемные строки 
    плюс N строк окружающего контекста
-json
    выводить аналитическую диагностику 
    (и ошибки) в формате JSON


Читайте также:


Команда gofmt в Golang

gofmt форматирует программы Go. Используются табы для отступа и пробелы для выравнивания. Выравнивание предполагает, что редактор использует шрифт фиксированной ширины.

Без явного пути обрабатывает стандартный ввод. При указании файла работает с этим файлом; при указании каталога рекурсивно работает со всеми файлами .go в этом каталоге. (Файлы, начинающиеся с точки, игнорируются.) По умолчанию gofmt печатает переформатированные источники на стандартный вывод.

Использование:

gofmt [flags] [path ...]

Флаги:

-d
    Не печатать отформатированные источники 
    на стандартный вывод.
    Если форматирование файла отличается от gofmt, 
    вывести diff на стандартный вывод.
-e
    Распечатать все (включая ложные) ошибки.
-l
    Не печатать отформатированные источники 
    на стандартный вывод.
    Если форматирование файла отличается от формата gofmt, 
    вывести его имя на стандартный вывод.
-r rule
    Применить правило (rule) перезаписи 
    к источнику перед переформатированием.
-s
    Попробовать упростить код 
    (после применения правила перезаписи, если оно есть).
-w
    Не печатать отформатированные источники 
    на стандартный вывод.
    Если форматирование файла отличается от формата gofmt, 
    перезаписать его версией gofmt. 
    Если во время перезаписи произошла ошибка,
    исходный файл восстанавливается 
    из автоматического резервного копирования.

Поддержка отладки:

-cpuprofile filename
    Записать профиль процессора в указанный файл.

Правило перезаписи, указанное с флагом -r, должно быть строкой вида:

pattern -> replacement

Шаблон (pattern) и замена (replacement) должны быть валидными выражениями Go. В шаблоне односимвольные строчные идентификаторы служат подстановочными знаками, соответствующими произвольным подвыражениям; эти выражения будут заменены теми же идентификаторами при замене.

Когда gofmt читает из стандартного ввода, он принимает либо полную программу Go, либо фрагмент программы. Фрагмент программы должен быть синтаксически допустимым списком объявлений, списком утверждений или выражением. При форматировании такого фрагмента gofmt сохраняет начальные отступы, а также начальные и конечные пробелы, так что отдельные разделы программы Go могут быть отформатированы путем передачи их через gofmt.

Примеры использования gofmt

Чтобы проверить файлы на наличие ненужных скобок:

gofmt -r '(a) -> a' -l *.go

Чтобы удалить скобки:

gofmt -r '(a) -> a' -w *.go

Чтобы преобразовать дерево пакетов из явных верхних границ среза в неявные:

gofmt -r 'α[β:len(α)] -> α[β:]' -w $GOROOT/src

Команда simplify (упростить)

При вызове с -s gofmt по возможности сделает следующие исходные преобразования.

Составной литерал массива, среза или карты в форме:
    []T{T{}, T{}}
будет упрощено до:
    []T{{}, {}}

Выражение среза формы:
    s[a:len(s)]
будет упрощено до:
    s[a:]

Диапазон (range) формы:
    for x, _ = range v {...}
будет упрощено до:
    for x = range v {...}

Диапазон (range) формы:
    for _ = range v {...}
будет упрощено до:
    for range v {...}

Это может привести к изменениям, которые несовместимы с более ранними версиями Go.


Читайте также:


купить игрушку gopher

среда, 17 июля 2019 г.

Команда fix в Golang

fix находит программы Go, использующие старые API, и переписывает их для использования более новых. После обновления до новой версии Go fix помогает внести необходимые изменения в ваших программах.

Использование:

go tool fix [-r name,...] [path ...]

Без явного пути fix читает стандартный ввод и записывает результат в стандартный вывод.

Если именованный путь является файлом, fix перезаписывает именованные файлы на месте. Если именованный путь является каталогом, fix переписывает все файлы .go в этом дереве каталогов. Когда fix перезаписывает файл, он печатает строку со стандартной ошибкой, в которой указаны имя файла и примененная перезапись.

Если установлен флаг -diff, файлы не перезаписываются. Взамен fix печатает различия, которые внесет переписывание.

Флаг -r ограничивает количество рассматриваемых перезаписей теми, которые указаны в именованном списке. По умолчанию fix учитывает все известные изменения. Переписывания исправлений идемпотентны, поэтому можно безопасно применять исправления к обновленному или частично обновленному коду даже без использования флага -r.

Fix выводит полный список исправлений, которые он может применить в своем выводе справки; чтобы увидеть их, запустите go tool fix -help.

Fix не делает резервные копии файлов, которые он редактирует. Вместо этого используйте функциональность “diff” системы контроля версий для проверки изменений, которые вносит fix, перед тем как выполнить коммит.


Читайте также:


понедельник, 1 июля 2019 г.

Команды go: go vet, сообщить о возможных ошибках в пакетах

Использование:

go vet [-n] [-x] [-vettool prog] [build flags] [vet flags] [packages]

vet запускает команду go vet для пакетов, названных путями импорта.

Для получения дополнительной информации о vet и его флагах см. go doc cmd/vet. Подробнее об указании пакетов см. go help packages. Список проверок и их флагов см. go tool vet help. Для получения подробной информации о конкретном контролере, таком как 'printf', смотрите go tool vet help printf.

Флаг -n печатает команды, которые будут выполнены. Флаг -x печатает команды по мере их выполнения.

Флаг -vettool=prog выбирает другой инструмент анализа с альтернативными или дополнительными проверками. Например, теневой ('shadow') анализатор может быть построен и запущен с использованием этих команд:

go install golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow
go vet -vettool=$(which shadow)

Флаги сборки (build flags), поддерживаемые go vet, контролируют разрешение и выполнение пакета, например -n, -x, -v, -tags и -toolexec. Для получения дополнительной информации об этих флагах см. go help build.

Смотрите также: go fmt, go fix.


Читайте также:


Команды go: go version, напечатать версию Go

Использование:

go version

version печатает версию Go, как сообщает runtime.Version.


Читайте также:


Команды go: go tool, запустить указанный инструмент go

Использование:

go tool [-n] command [args...]

tool запускает команду go tool, идентифицированную аргументами. Без аргументов выводит список известных инструментов.

Флаг -n заставляет tool напечатать команду, которая будет выполнена, но не выполнит ее.

Подробнее о каждой команде инструмента см. go doc cmd/<command>.


Читайте также:


воскресенье, 30 июня 2019 г.

Команды go: go test, тестировать пакеты

Использование:

go test [build/test flags] [packages] [build/test flags & test binary flags]

go test автоматизирует тестирование пакетов, названных путями импорта. Он печатает резюме результатов теста в формате:

ok   archive/tar   0.011s
FAIL archive/zip   0.022s
ok   compress/gzip 0.033s
...

с последующим подробным выводом для каждого неудачного пакета.

go test перекомпилирует каждый пакет вместе с любыми файлами с именами, соответствующими шаблону файла *_test.go. Эти дополнительные файлы могут содержать функции тестирования, эталонные (benchmark) функции и примеры функций. Смотрите 'go help testfunc' для более подробной информации. Каждый перечисленный пакет вызывает выполнение отдельного тестового бинарного файла. Файлы, имена которых начинаются с "_" (включая "_test.go") или "." игнорируются

Тестовые файлы, которые объявляют пакет с суффиксом "_test", будут скомпилированы как отдельный пакет, а затем связаны и запущены с основным тестовым бинарным файлом.

Инструмент go игнорирует каталог с именем "testdata", делая его доступным для хранения вспомогательных данных, необходимых для тестов.

В рамках создания бинарного теста go test выполняет go vet для пакета и его исходных файлов для выявления значительных проблем. Если go vet обнаружит какие-либо проблемы, go test сообщит их и не запустит бинарный файл теста. Используется только подмножество с высокой достоверностью проверок по умолчанию. Это подмножество: 'atomic', 'bool', 'buildtags', 'nilfunc' и 'printf'. Вы можете просмотреть документацию для этих и других vet тестов через "go doc cmd/vet". Чтобы отключить запуск go vet, используйте флаг -vet=off.

Все выходные данные теста и итоговые строки выводятся на стандартный вывод команды go, даже если тест выводит их со своей собственной стандартной ошибкой. (Стандартная ошибка команды go зарезервирована для ошибок печати при построении тестов.)

Go test выполняется в двух разных режимах:

Первый, называемый режимом локального каталога, возникает, когда go test вызывается без аргументов пакета (например, 'go test' или 'go test -v'). В этом режиме go test компилирует исходные коды пакетов и тесты, найденные в текущем каталоге, а затем запускает полученный тестовый бинарный файл. В этом режиме кэширование (обсуждается ниже) отключено. После того, как пакетный тест завершится, go test напечатает итоговую строку, показывающую статус теста ('ok' или 'FAIL'), имя пакета и истекшее время.

Второй, называемый режимом списка пакетов, возникает, когда go test вызывается с явными аргументами пакета (например, 'go test math', 'go test ./...' и даже 'go test .'). В этом режиме go test скомпилирует и протестирует каждый из пакетов, перечисленных в командной строке. Если пакетный тест пройден, go test печатает только последнюю итоговую строку 'ok'. Если пакетный тест не пройден, go test распечатывает полный тестовый вывод. Если вызывается с флагом -bench или -v, go test печатает полный вывод даже для прохождения пакетных тестов, чтобы отобразить запрошенные результаты тестов или подробное ведение журнала.

Только в режиме списка пакетов, go test кэширует успешные результаты тестирования пакета, чтобы избежать ненужного повторного запуска тестов. Когда результаты теста могут быть восстановлены из кэша, go test перезапустит предыдущий вывод вместо повторного запуска тестового бинарного файла. Когда это происходит, go test печатает '(cached)' вместо истекшего времени в итоговой строке.

Правило совпадения в кеше заключается в том, что в прогоне используется один и тот же тестовый бинарный файл, а флаги в командной строке целиком исходят из ограниченного набора "кэшируемых" ('cacheable') тестовых флагов, определенных как -cpu, -list, -parallel, -run, -short, и -v. Если запуск go test имеет какие-либо тестовые или не тестовые флаги вне этого набора, результат не кэшируется. Чтобы отключить кэширование тестов, используйте любой тестовый флаг или аргумент, кроме кешируемых флагов. Идиоматический способ явного отключения кэширования тестов - использовать -count=1. Тесты, которые открывают файлы внутри корня исходного кода пакета (обычно $GOPATH) или которые обращаются к переменным среды, соответствуют только будущим прогонам, в которых файлы и переменные среды не изменяются. Кэшированный результат теста обрабатывается как выполняющийся в кратчайшие сроки, поэтому успешный результат теста пакета будет кэшироваться и использоваться повторно независимо от значения параметра -timeout.

В дополнение к флагам сборки, флаги, обрабатываемые самим 'go test':

-args
    Передать остаток от командной строки (все после -args)
    бинарному тесту, без интерпретации и без изменений.
    Поскольку этот флаг потребляет оставшуюся часть командной строки,
    список пакетов (если имеется) должен появляться перед этим флагом.

-с
    Скомпилировать тестовый бинарный файл в pkg.test, но не запускать его
    (где pkg - последний элемент пути импорта пакета).
    Имя файла можно изменить с помощью флага -o.

-exec xprog
    Запустить тестовый бинарный файл с помощью xprog. Поведение такое же, как
    в 'go run'. Смотрите подробности в 'go help run'.

-i
    Установить пакеты, которые являются зависимостями теста.
    Не запускать тест.

-json
    Преобразовать выходные данные теста в формат JSON, подходящий для автоматической обработки.
    Смотрите 'go doc test2json' для деталей кодирования.

-o file
    Скомпилировать бинарный файл теста в указанный файл.
    Тест все еще выполняется (если не указано -c или -i).

Бинарный файл теста также принимает флаги, которые управляют выполнением теста; эти флаги также доступны в 'go test'. Смотрите 'go help testflag' для подробностей.

Для получения дополнительной информации о флагах сборки см. go help build. Подробнее об указании пакетов см. go help packages.

Смотрите также: go build, go vet.


Читайте также:


суббота, 29 июня 2019 г.

Команды go: go run, скомпилировать и запустить Go программу

Использование:

go run [build flags] [-exec xprog] package [arguments...]

run компилирует и запускает указанный основной Go пакет. Обычно пакет указывается в виде списка исходных файлов .go, но это также может быть путь импорта, путь файловой системы или шаблон, соответствующий одному известному пакету, как в 'go run .' или 'go run my/cmd'.

По умолчанию 'go run' запускает скомпилированный бинарный файл напрямую: 'a.out arguments...'. Если указан флаг -exec, 'go run' вызывает бинарный файл, используя xprog:

'xprog a.out arguments...'.

Если флаг -exec не задан, GOOS или GOARCH отличается от системного значения по умолчанию, и программа с именем go_$GOOS_$GOARCH_exec может быть найдена в текущем пути поиска, 'go run' вызывает бинарный файл с использованием этой программы, например 'go_nacl_386_exec a.out arguments ...'. Это позволяет выполнять кросс-компилированные программы, когда доступен симулятор или другой метод выполнения.

Состояние выхода run не является состоянием выхода скомпилированного бинарного файла.

Для получения дополнительной информации о флагах сборки см. go help build. Подробнее об указании пакетов см. go help packages.

Смотрите также: go build.


Читайте также:


Команды go: go mod why, объяснение необходимости пакета или модуля

Использование:

go mod why [-m] [-vendor] packages...

why показывает кратчайший путь на графе импорта из основного модуля к каждому из перечисленных пакетов. Если указан флаг -m, why обрабатывает аргументы как список модулей и находит путь к любому пакету в каждом из модулей.

По умолчанию, why запрашивает граф пакетов, сопоставленных с "go list all", который включает в себя тесты для достижимых пакетов. Флаг -vendor вызывает необходимость исключать проверки зависимостей.

Выходные данные представляют собой последовательность разделов, по одному для каждого имени пакета или модуля в командной строке, разделенных пустыми строками. Каждый раздел начинается со строки комментария "# package" или "# module", в которой указан целевой пакет или модуль. Последующие строки дают путь через граф импорта, один пакет на строку. Если на пакет или модуль не ссылаются из основного модуля, раздел отображает одну заключенную в скобки заметку с указанием этого факта.

Например:

$ go mod why golang.org/x/text/language golang.org/x/text/encoding
# golang.org/x/text/language
rsc.io/quote
rsc.io/sampler
golang.org/x/text/language

# golang.org/x/text/encoding
(main module does not need package golang.org/x/text/encoding)
$


Читайте также:


Команды go: go mod verify, проверка достоверности зависимостей

Использование:

go mod verify

verify проверяет, что зависимости текущего модуля, которые хранятся в локальном загруженном исходном кеше, не были изменены с момента загрузки. Если все модули не изменены, verify печает "all modules verified". В противном случае он сообщает, какие модули были изменены, и вызывает 'go mod' для выхода с ненулевым статусом.


Читайте также:


Команды go: go mod vendor, сделать вендорную копию зависимостей

Использование:

go mod vendor [-v]

vendor сбрасывает каталог поставщика (vendor directory) основного модуля, чтобы включить все пакеты, необходимые для сборки и тестирования всех пакетов основного модуля. Он не включает тестовый код для вендорных пакетов.

Флаг -v заставляет vendor печатать имена вендорных модулей и пакетов в вывод стандартной ошибки.


Читайте также:


четверг, 27 июня 2019 г.

Команды go: go mod tidy, добавить отсутствующие и удалить неиспользуемые модули

Использование:

go mod tidy [-v]

tidy удостоверяется, что go.mod соответствует исходному коду в модуле. Он добавляет все недостающие модули, необходимые для построения пакетов и зависимостей текущего модуля, и удаляет неиспользуемые модули, которые не предоставляют никаких соответствующих пакетов. Он также добавляет все недостающие записи в go.sum и удаляет ненужные.

Флаг -v заставляет tidy печатать информацию об удаленных модулях в стандартный вывод ошибки (std err).


Читайте также:


Команды go: go mod init, инициализировать новый модуль в текущем каталоге

Использование:

go mod init [module]

init инициализирует и записывает новый go.mod в текущий каталог, фактически создавая новый модуль с корнем в текущем каталоге. Файл go.mod не должен уже существовать. Если возможно, init будет угадывать путь к модулю из комментариев к импорту (см. go help importpath) или из конфигурации управления версиями. Чтобы переопределить это предположение, укажите путь к модулю в качестве аргумента.


Читайте также:


Команды go: go mod graph, распечатать граф требований модуля

Использование:

go mod graph

graph печатает граф требований модуля (с примененными заменами) в текстовом виде. Каждая строка в выходных данных имеет два поля, разделенных пробелами: модуль и одно из его требований. Каждый модуль идентифицируется как строка в форме path@version, за исключением основного модуля, у которого нет суффикса @version.


Читайте также:


Команды go: go mod edit, редактирование go.mod из инструментов или скриптов

Использование:

go mod edit [editing flags] [go.mod]

Edit предоставляет интерфейс командной строки для редактирования go.mod, для использования в основном инструментами или скриптами. Он читает только go.mod; он не ищет информацию о задействованных модулях. По умолчанию edit читает и записывает файл go.mod основного модуля, но после флагов редактирования можно указать другой целевой файл.

Флаги редактирования определяют последовательность операций редактирования.

Флаг -fmt переформатирует файл go.mod без внесения других изменений. Это переформатирование также подразумевается любыми другими модификациями, которые используют или переписывают файл go.mod. Единственный раз, когда нужен этот флаг, это если другие флаги не указаны, как в 'go mod edit -fmt'.

Флаг -module изменяет путь к модулю (строка модуля файла go.mod).

Флаги -require=path@version и -droprequire=path добавляют и отбрасывают требование к указанному пути и версии модуля. Обратите внимание, что -require отменяет любые существующие требования к пути. Эти флаги в основном предназначены для инструментов, которые понимают граф модуля. Пользователи должны предпочесть 'go get path@version' или 'go get path@none', которые при необходимости выполняют другие корректировки go.mod для удовлетворения ограничений, накладываемых другими модулями.

Флаги -exclude=path@version и -dropexclude=path@version добавляют и удаляют исключение для заданного пути и версии модуля. Обратите внимание, что -exclude=path@version не допускается, если это исключение уже существует.

Флаги -replace=old[@v]=new[@v] и -dropreplace=old[@v] добавляют и удаляют замену указанного пути к модулю и пары версий. Если @v в old@v опущено, замена применяется ко всем версиям со старым путем к модулю. Если @v в new@v опущен, новый путь должен быть корневым каталогом локального модуля, а не путем к модулю. Обратите внимание, что -replace заменяет любые существующие замены для old[@v].

Флаги редактирования -require, -droprequire, -exclude, -dropexclude, -replace и -dropreplace могут быть повторены, и изменения применяются в указанном порядке.

Флаг -go=version устанавливает ожидаемую версию языка Go.

Флаг -print печатает окончательный вариант go.mod в текстовом формате, а не записывает его обратно в go.mod.

Флаг -json печатает конечный файл go.mod в формате JSON, а не записывает его обратно в go.mod. Вывод JSON соответствует этим типам Go:

type Module struct {
    Path string
    Version string
}

type GoMod struct {
    Module  Module
    Go      string
    Require []Require
    Exclude []Module
    Replace []Replace
}

type Require struct {
    Path string
    Version string
    Indirect bool
}

type Replace struct {
    Old Module
    New Module
}

Обратите внимание, что это описывает только сам файл go.mod, а не другие модули, на которые ссылаются косвенно. Для полного набора модулей, доступных для сборки, используйте 'go list -m -json all'.

Например, инструмент может получить go.mod как структуру данных, проанализировав выходные данные 'go mod edit -json', а затем может внести изменения, вызвав 'go mod edit' с -require, -exclude и так далее.


Читайте также:


Команды go: go mod download, загрузка модулей в локальный кеш

Использование:

go mod download [-json] [modules]

download загружает названные модули, которые могут быть шаблонами модулей, выбирающими зависимости основного модуля, или запросами модулей вида path@version. Без аргументов download применяется ко всем зависимостям основного модуля.

Команда go автоматически загружает модули по мере необходимости во время обычного выполнения. Команда "go mod download" полезна в основном для предварительного заполнения локального кэша или для вычисления ответов от прокси Go модуля.

По умолчанию download сообщает об ошибках в вывод стандартной ошибки (std err), но в остальном молчит. Флаг -json заставляет download печатать последовательность объектов JSON в стандартный вывод, описывая каждый загруженный модуль (или сбой), соответствующий этой Go структуре:

type Module struct {
    Path     string // путь к модулю
    Version  string // версия модуля
    Error    string // ошибка загрузки модуля
    Info     string // абсолютный путь к кешированному файлу .info
    GoMod    string // абсолютный путь к кешированному файлу .mod
    Zip      string // абсолютный путь к кешированному .zip файлу
    Dir      string // абсолютный путь к кешированному корневому каталогу источника
    Sum      string // контрольная сумма для пути, версии (как в go.sum)
    GoModSum string // контрольная сумма для go.mod (как в go.sum)
}

Смотрите 'go help modules' для получения дополнительной информации о запросах модулей.


Читайте также:


Команды go: go mod, обслуживание модуля

go mod обеспечивает доступ к операциям над модулями.

Обратите внимание, что поддержка модулей встроена во все команды go, а не только в 'go mod'. Например, ежедневное добавление, удаление, обновление и понижение зависимостей должны выполняться с помощью 'go get'. См. 'go help modules' для обзора функциональности модуля.

Использование:

go mod <command> [arguments]

Команды (command):

download    скачать модули в локальный кеш
edit        редактировать go.mod из инструментов или скриптов
graph       напечатать граф требований модуля
init        инициализировать новый модуль в текущем каталоге
tidy        добавить отсутствующие и удалить неиспользуемые модули
vendor      делает вендорную копию зависимостей
verify      проверить зависимости ожидаемого содержания
why         объяснять, зачем нужны пакеты или модули

Используйте "go help mod <command>" для получения дополнительной информации о команде.


Читайте также:


Команды go: go list, вывод списка пакетов или модулей

Использование:

go list [-f format] [-json] [-m] [list flags] [build flags] [packages]

list выводит список именованных пакетов, по одному на строку. Чаще всего используются флаги -f и -json, которые управляют формой вывода, напечатанной для каждого пакета. Другие флаги списка, описанные ниже, контролируют более конкретные детали.

Вывод по умолчанию показывает путь импорта пакета:

bytes
encoding/json
github.com/gorilla/mux
golang.org/x/net/html

Флаг -f указывает альтернативный формат для списка, используя синтаксис шаблона пакета. Вывод по умолчанию эквивалентен -f '{{.ImportPath}}'. Структура, передаваемая в шаблон:

type Package struct {
    Dir           string   // каталог, содержащий исходный код пакета
    ImportPath    string   // путь импорта пакета в dir
    ImportComment string   // путь в import комментарии в утверждении пакета (package statement)
    Name          string   // имя пакета
    Doc           string   // строка документации пакета
    Target        string   // путь установки
    Shlib         string   // разделяемая (shared) библиотека, которая содержит этот пакет (устанавливается только когда -linkshared)
    Goroot        bool     // этот пакет в Go root?
    Standard      bool     // этот пакет является частью стандартной Go библиотеки?
    Stale         bool     // будет ли 'go install' делать что-либо с этим пакетом?
    StaleReason   string   // объяснение для Stale==true
    Root          string   // Go root или Go path dir содержащий этот пакет
    ConflictDir   string   // эта директория затеняет(shadows) Dir в $GOPATH
    BinaryOnly    bool     // бинарный пакет: не может быть перекомпилирован из исходных файлов
    ForTest       string   // пакет только для использования в именованном тесте
    Export        string   // файл, содержащий данные экспорта (при использовании -export)
    Module        *Module  // информация о модуле, содержащем пакет, если есть (может быть nil)
    Match         []string // шаблоны командной строки, соответствующие этому пакету
    DepOnly       bool     // пакет является только зависимостью, явно не перечисляемой

    // Исходные файлы
    GoFiles         []string // .go исходные файлы (исключая CgoFiles, TestGoFiles, XTestGoFiles)
    CgoFiles        []string // .go исходные файлы которые импортируют "C"
    CompiledGoFiles []string // .go файлы, представленные компилятору (при использовании -compiled)
    IgnoredGoFiles  []string // .go исходные файлы игнориремые из-за ограничений сборки
    CFiles          []string // .c исходные файлы
    CXXFiles        []string // .cc, .cxx и .cpp исходные файлы
    MFiles          []string // .m исходные файлы
    HFiles          []string // .h, .hh, .hpp и .hxx исходные файлы
    FFiles          []string // .f, .F, .for и .f90 Fortran исходные файлы
    SFiles          []string // .s исходные файлы
    SwigFiles       []string // .swig файлы
    SwigCXXFiles    []string // .swigcxx файлы
    SysoFiles       []string // .syso object файлы для добавления в архив
    TestGoFiles     []string // _test.go файлы в пакете
    XTestGoFiles    []string // _test.go файлы во внешнем пакете

    // Cgo директивы
    CgoCFLAGS    []string // cgo: флаги для C компилятора
    CgoCPPFLAGS  []string // cgo: флаги для C препроцессора
    CgoCXXFLAGS  []string // cgo: флаги для C++ компилятора
    CgoFFLAGS    []string // cgo: флаги для Fortran компилятора
    CgoLDFLAGS   []string // cgo: флаги для линкера (linker)
    CgoPkgConfig []string // cgo: pkg-config имена
    // Информация о зависимости
    Imports      []string          // import использованные для этого пакета
    ImportMap    map[string]string // карта (map) из исходного import в ImportPath (идентификационные записи опущены)
    Deps         []string          // все (рекурсивно) импортированные зависимости
    TestImports  []string          // импорты из TestGoFiles
    XTestImports []string          // импорты из XTestGoFiles

    // Информация об ошибке
    Incomplete bool            // этот пакет или зависимость имеет ошибку
    Error      *PackageError   // ошибка загрузки пакета
    DepsErrors []*PackageError // ошибки загрузки зависимостей
}

Пакеты, хранящиеся в каталогах поставщиков (vendor directories), сообщают о ImportPath, который включает путь к каталогу поставщика (например, "d/vendor/p" вместо "p"), так что ImportPath уникально идентифицирует данную копию пакета. Списки Imports, Deps, TestImports и XTestImports также содержат эти расширенные пути импорта.

Информация об ошибке, если таковая имеется,

type PackageError struct {
    ImportStack   []string // кратчайший путь от пакета, названного в командной строке, к этому
    Pos           string   // позиция ошибки (если есть, файл:строка:столбец)
    Err           string   // сама ошибка
}

Информация модуля является Module структурой, определенной в обсуждении списка -m ниже.

Функция шаблона "join" вызывает strings.Join.

Функция шаблона "context" возвращает контекст сборки, определенный как:

type Context struct {
    GOARCH        string   // целевая архитектура
    GOOS          string   // целевая операционная система
    GOROOT        string   // Go root
    GOPATH        string   // Go path
    CgoEnabled    bool     // можно ли использовать cgo
    UseAllFiles   bool     // использовать файлы независимо от +build строк, имен файлов
    Compiler      string   // компилятор для предположения при вычислении целевых путей
    BuildTags     []string // build огрничения для соотвествия в +build строках
    ReleaseTags   []string // выпуска текущего релиза совместимого с
    InstallSuffix string   // суффикс для использования в имени установочного каталога
}

Для получения дополнительной информации о значении этих полей см. документацию для типа Context пакета go/build.

Флаг -json заставляет печатать данные пакета в формате JSON вместо использования формата шаблона.

Флаг -compiled заставляет список устанавливать CompiledGoFiles в исходные файлы Go, представленные компилятору. Обычно это означает, что он повторяет файлы, перечисленные в GoFiles, а затем также добавляет код Go, сгенерированный путем обработки CgoFiles и SwigFiles. Список Imports содержит объединение всех импортов из GoFiles и CompiledGoFiles.

Флаг -deps заставляет list перебирать не только именованные пакеты, но и все их зависимости. Он просматривает их в глубине первого обхода после заказа, так что пакет перечисляется только после всех его зависимостей. Для пакетов, явно не указанных в командной строке, для поля DepOnly будет установлено значение true.

Флаг -e изменяет обработку ошибочных пакетов, которые не могут быть найдены или искажены. По умолчанию команда list выводит ошибку на стандартную ошибку для каждого ошибочного пакета и не учитывает пакеты при обычной печати. С флагом -e команда list никогда не печатает ошибки в стандартную ошибку и вместо этого обрабатывает ошибочные пакеты обычной печатью. Ошибочные пакеты будут иметь непустое поле ImportPath и не нулевую Error; другая информация может отсутствовать или может не отсутствовать (обнулена).

Флаг -export приводит к тому, что list устанавливает в поле Export имя файла, содержащего актуальную информацию об экспорте для данного пакета.

Флаг -find заставляет список идентифицировать именованные пакеты, но не разрешать их зависимости: списки Imports и Deps будут пустыми.

Флаг -test заставляет list сообщать не только о названных пакетах, но и об их бинарных файлах тестов (для пакетов с тестами), чтобы передать инструментам анализа исходного кода, как именно создаются тестовые бинарные файлы. Указанный путь импорта для тестового бинарного файла - это путь импорта пакета, за которым следует суффикс ".test", как в "math/rand.test". При создании теста иногда необходимо перестроить определенные зависимости специально для этого теста (чаще всего сам тестируемый пакет). Указанный путь импорта пакета, перекомпилированного для конкретного тестового бинарного файла, сопровождается пробелом и именем тестового бинарного файла в скобках, как в "math/rand [math/rand.test]" или "regexp [sort.test]". В поле ForTest также указывается имя тестируемого пакета ("math/rand" или "sort" в предыдущих примерах).

Пути к файлам Dir, Target, Shlib, Root, ConflictDir и Export - это абсолютные пути.

По умолчанию списки GoFiles, CgoFiles и т.д. Содержат имена файлов в Dir (то есть пути относительно Dir, а не абсолютные пути). Сгенерированные файлы, добавленные при использовании флагов -compiled и -test, представляют собой абсолютные пути, ссылающиеся на кэшированные копии сгенерированных исходных файлов Go. Хотя они являются исходными файлами Go, пути могут не заканчиваться на ".go".

Флаг -m заставляет list перечислять модули вместо пакетов.

При перечислении модулей флаг -f по-прежнему указывает шаблон формата, применяемый к Go структуре, но теперь это Module структура:

type Module struct {
    Path     string       // путь к модулю
    Version  string       // версия модуля
    Versions []string     // доступные версии модуля (с -versions)
    Replace  *Module      // замещен на этот модуль
    Time     *time.Time   // временная версия была создана
    Update   *Module      // доступно обновление, если есть (с -u)
    Main     bool         // это основной (main) модуль?
    Indirect bool         // является ли этот модуль только косвенной зависимостью основного модуля?
    Dir      string       // каталог, содержащий файлы для этого модуля, если есть
    GoMod    string       // путь к файлу go.mod для этого модуля, если есть
    Error    *ModuleError // ошибка загрузки модуля
}

type ModuleError struct {
    Err string // сама ошибка
}

По умолчанию выводится путь к модулю, а затем информация о версии и замене, если таковые имеются. Например, 'go list -m all' может вывести:

my/main/module
golang.org/x/text v0.3.0 => /tmp/text
rsc.io/pdf v0.1.1

Структура Module имеет метод String, который форматирует эту строку вывода, поэтому формат по умолчанию эквивалентен -f '{{.String}}'.

Обратите внимание, что когда модуль был заменен, его поле Replace описывает модуль замены, а его поле Dir устанавливается на исходный код замены, если таковой имеется. (То есть, если Replace не ноль, тогда Dir установлен в Replace.Dir, без доступа к замененному исходному коду.)

Флаг -u добавляет информацию о доступных обновлениях. Когда последняя версия данного модуля новее текущей, list -u устанавливает в поле Update в Module информацию о более новом модуле. Метод String модуля указывает доступное обновление путем форматирования новой версии в скобках после текущей версии. Например, 'go list -m -u all' может вывести:

my/main/module
golang.org/x/text v0.3.0 [v0.4.0] => /tmp/text
rsc.io/pdf v0.1.1 [v0.1.2]

(Для инструментов 'go list -m -u -json all' может быть удобнее анализировать.)

Флаг -versions приводит к тому, что list устанавливает в поле Versions модуля список всех известных версий этого модуля, упорядоченных в соответствии с семантической версией, начиная с самой ранней и последней версии. Флаг также изменяет формат вывода по умолчанию для отображения пути к модулю, за которым следует разделенный пробелами список версий.

Аргументы для списка -m интерпретируются как список модулей, а не пакетов. Основным модулем является модуль, содержащий текущий каталог. Активные модули являются основным модулем и его зависимостями. Без аргументов list -m показывает основной модуль. С аргументами list -m показывает модули, указанные аргументами. Любой из активных модулей может быть указан его путем к модулю. Специальный шаблон "all" определяет все активные модули, сначала основной модуль, а затем зависимости, отсортированные по пути модуля. Шаблон, содержащий "...", указывает активные модули, чьи пути модулей соответствуют шаблону. Запрос формы path@version указывает результат этого запроса, который не ограничивается активными модулями. Смотрите 'go help modules' для получения дополнительной информации о запросах модулей.

Функция шаблона "module" принимает один строковый аргумент, который должен быть путем к модулю или запросом, и возвращает указанный модуль в виде структуры модуля. Если произойдет ошибка, результатом будет структура модуля с полем Error, отличным от nil.

Для получения дополнительной информации о флагах сборки см. 'go help build'.

Подробнее об указании пакетов см. 'go help packages'.

Для получения дополнительной информации о модулях см. 'go help modules'.


Читайте также: