Go Tool: Difference between revisions
(→get) |
(→doc) |
||
| (6 intermediate revisions by the same user not shown) | |||
| Line 50: | Line 50: | ||
go clean -fuzzcache | go clean -fuzzcache | ||
</syntaxhighlight> | </syntaxhighlight> | ||
==<tt>link</tt>== | |||
{{Internal|go tool link#Overview|<tt>go tool link</tt>}} | |||
==<tt>doc</tt>== | ==<tt>doc</tt>== | ||
{{Internal|Go_doc#Overview|<tt>go doc</tt>}} | |||
< | |||
</ | |||
==<span id='fmt'></span><tt>fmt</tt> (<tt>gofmt</tt>)== | ==<span id='fmt'></span><tt>fmt</tt> (<tt>gofmt</tt>)== | ||
{{ | {{Internal|Go_fmt#Overview|<tt>go fmt</tt>}} | ||
==<tt>get</tt>== | ==<tt>get</tt>== | ||
The <code>get</code> command downloads packages and installs them. It does that by connecting to the remote repository that maintains the package source code and downloading the source tree locally. <code>get</code> is the preferred way to update <code>go.mod</code> with a new dependency: | The <code>get</code> command downloads packages and installs them, possibly updating a local obsolete version. It does that by connecting to the remote repository that maintains the package source code and downloading the source tree locally. <code>get</code> is the preferred way to update <code>go.mod</code> with a new dependency: | ||
{{Internal|Go.mod#Adding_a_Dependency_to_a_Module|<tt>go.mod</tt> | <tt>go get</tt>}} | {{Internal|Go.mod#Adding_a_Dependency_to_a_Module|<tt>go.mod</tt> | <tt>go get</tt>}} | ||
Once <code>go.mod</code> has been updated by <code>go get</code>, the package's import pat can be used in the project's <code>[[Go_Packages#Import_Statement|import]]</code> statements. | Once <code>go.mod</code> has been updated by <code>go get</code>, the package's import pat can be used in the project's <code>[[Go_Packages#Import_Statement|import]]</code> statements. | ||
| Line 90: | Line 73: | ||
===Problems with <tt>get</tt>=== | ===Problems with <tt>get</tt>=== | ||
<font color=darkkhaki>The <code>import</code> statement drives <code>go get</code> but the <code>import</code> statement does not contain sufficient information to identify which revision of a package should be fetched any time <code>go get</code> is called. The possibility that <code>go get</code> can fetch a different version of code for any given package at any time makes supporting the Go tooling in any reproducible solution complicated and tedious.</font> | <font color=darkkhaki>The <code>import</code> statement drives <code>go get</code> but the <code>import</code> statement does not contain sufficient information to identify which revision of a package should be fetched any time <code>go get</code> is called. The possibility that <code>go get</code> can fetch a different version of code for any given package at any time makes supporting the Go tooling in any reproducible solution complicated and tedious.</font> | ||
===Options=== | ===Options=== | ||
====<tt>-u</tt>==== | ====<tt>-u</tt>==== | ||
| Line 104: | Line 88: | ||
==<tt>list</tt>== | ==<tt>list</tt>== | ||
{{Internal|Go_list#Overview|<tt>go list</tt>}} | |||
==<tt>test</tt>== | ==<tt>test</tt>== | ||
Latest revision as of 23:36, 5 July 2024
External
Internal
Overview
go is a command line tool with multiple uses: package manager, build tool and test driver. go manage packages in workspaces, query metadata about packages, print documentation, build, format, download, test, etc.
Commands
Help
go help <command>
go help build
build
install
run
The run command compiles the specified packages or files by delegating to go build and then runs the executable. There must be a main for an executable to be generated.
cd $PROJECT_DIR
go run ./src/main/main.go some-arg-1 some-arg-2
The first argument that does not end in .go is assumed to be the beginning of the list of command line arguments of the executable.
Is the above true though? The following command runs fine, where "example.com/experimental-go-module/cmd/gotest" is the package path of a "main" package inside of the "example.com/experimental-go-module" module. No argument ends in .go, yet it works:
go run example.com/experimental-go-module/cmd/gotest
The shared flags described here apply:
clean
The shared flags described here apply:
-cache
Clean the build cache:
go clean -cache
-fuzzcache
Clean the fuzz cache:
go clean -fuzzcache
link
doc
fmt (gofmt)
get
The get command downloads packages and installs them, possibly updating a local obsolete version. It does that by connecting to the remote repository that maintains the package source code and downloading the source tree locally. get is the preferred way to update go.mod with a new dependency:
Once go.mod has been updated by go get, the package's import pat can be used in the project's import statements.
go get is sensitive to the Git configuration present in ~/.gitconfig, especially repository configuration:
[url "git@github.example.com:some-repo"]
insteadOf = https://github.example.com/some-repo
The shared flags described here apply:
Problems with get
The import statement drives go get but the import statement does not contain sufficient information to identify which revision of a package should be fetched any time go get is called. The possibility that go get can fetch a different version of code for any given package at any time makes supporting the Go tooling in any reproducible solution complicated and tedious.
Options
-u
The -u flag instructs get to update modules providing dependencies of packages named on the command line to use newer minor or patch releases when available.
-d
Stop after downloading the package, do not install the package.
-f
Only valid when -u is set, forces get -u not to verify that each package has been checked out from the source control repository implied by its import path. This can be useful if the source is a local fork of the original.
-fix
Run the fix tool on the downloaded packages before resolving dependencies or building the code.
-t
Also download the packages required to build the tests for the specified packages.
list
test
env
mod
vet
Deplete: vet
version
Deplete version