Go get: Difference between revisions
(Created page with "=Internal= * <tt>go tool</tt> =Overview=") |
|||
Line 2: | Line 2: | ||
* [[Go_Tool#get|<tt>go tool</tt>]] | * [[Go_Tool#get|<tt>go tool</tt>]] | ||
=Overview= | =Overview= | ||
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>}} | |||
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. | |||
<code>go get</code> is sensitive to the Git configuration present in <code>~/.gitconfig</code>, especially repository configuration: | |||
<font size=-2> | |||
[url "git@github.example.com:some-repo"] | |||
insteadOf = https://github.example.com/some-repo | |||
</font> | |||
The shared flags described here apply: {{Internal|Go_Tool_Shared_Flags#Overview|Shared Flags}} | |||
===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> | |||
===Options=== | |||
====<tt>-u</tt>==== | |||
The <code>-u</code> flag instructs <code>get</code> to update modules providing dependencies of packages named on the command line to use newer minor or patch releases when available. | |||
====<tt>-d</tt>==== | |||
Stop after downloading the package, do not install the package. | |||
====<tt>-f</tt>==== | |||
Only valid when <code>[[#-u|-u]]</code> is set, forces <code>get -u</code> 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. | |||
====<tt>-fix</tt>==== | |||
Run the fix tool on the downloaded packages before resolving dependencies or building the code. | |||
====<tt>-t</tt>==== | |||
Also download the packages required to build the tests for the specified packages. |
Revision as of 08:08, 23 November 2024
Internal
Overview
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.