1
0
mirror of https://github.com/golang/go synced 2024-11-26 16:16:57 -07:00

doc/go1.14: go command behavior with GO111MODULE=on outside modules

Hopefully this won't affect many people, but it's a substantial change
in behavior for a specific case, so it's probably worth mentioning.

Updates #32027

Change-Id: I61cd50e93d0199e94b011cc90150e072b6bb10ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/216597
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This commit is contained in:
Jay Conrod 2020-01-27 15:29:29 -05:00
parent 6fbdfe4804
commit 74d366f484

View File

@ -217,6 +217,32 @@ TODO
of <code>GOINSECURE</code> is a comma-separated list of glob patterns.
</p>
<h4 id="commands-outside-modules">Commands outside modules</h4>
<p><!-- golang.org/issue/32027 -->
When module-aware mode is enabled explicitly (by setting
<code>GO111MODULE=on</code>), most module commands have more
limited functionality if no <code>go.mod</code> file is present. For
example, <code>go</code> <code>build</code>,
<code>go</code> <code>run</code>, and other build commands can only build
packages in the standard library and packages specified as <code>.go</code>
files on the command line.
</p>
<p>
Previously, the <code>go</code> command would resolve each package path
to the latest version of a module but would not record the module path
or version. This resulted in <a href="https://golang.org/issue/32027">slow,
non-reproducible builds</a>.
</p>
<p>
<code>go</code> <code>get</code> continues to work as before, as do
<code>go</code> <code>mod</code> <code>download</code> and
<code>go</code> <code>list</code> <code>-m</code> with explicit version
patterns.
</p>
<h4 id="incompatible-versions"><code>+incompatible</code> versions</h4>
<!-- golang.org/issue/34165 -->