cmd/go: "downloading" message is misleading when GOPROXY points to a local directory

[bsiegert]

Go version

go version go1.21.5 netbsd/amd64

What operating system and processor architecture are you using (go env)?

GO111MODULE=on
GOPATH=${WRKDIR}/.gopath
GOPROXY=file://${WRKDIR}/.goproxy
GOARCH="amd64"
GOHOSTOS="netbsd"
GOOS="netbsd"

What did you do?

When building packages in pkgsrc (as in other similar systems), there is a rule that there should be no downloads during the build. Instead, all downloads are in a separate phase, with checksumming.

During the build, we set GOPROXY to a file URL, as per above.

What did you expect to see?

Any accesses to the "proxy" (which, again, is a local directory) still show a message like

go: downloading golang.org/x/tools v0.14.1-0.20231114185516-c9d3e7de13fd

What did you see instead?

I would not expect a message saying "downloading" when using a file URL. Maybe "using" or "accessing" would be better in this case.

See http://mail-index.netbsd.org/tech-pkg/2023/12/23/msg028661.html for a thread where someone was genuinely confused, thinking the message means modules are being downloaded over the network.

[dr2chase]

@bcmills

[bcmills]

“copying” would probably be a better word in this case.

[gopherbot]

Change https://go.dev/cl/554035 mentions this issue: cmd/go: change file url goproxy misleading messages

[bcmills]

Hmm. In general GOPROXY can be a list, which could mix file:// and https:// URLs in some arbitrary fallback order. Then there isn't one clear choice of verb.

@bsiegert, as an alternative, could you set GOMODCACHE to the pre-downloaded cache (instead of GOPROXY), and then run the build phase with GOPROXY=off?

[bsiegert]

We probably could but it's not a 1:1 replacement. The format of GOMODCACHE is pretty different.

[bcmills]

Generally the GOPROXY data is a subset of the GOMODCACHE contents. (That is: a GOMODCACHE is a valid GOPROXY, but converting a GOPROXY corpus to a GOMODCACHE may require the go command to do a little unpacking.)