run go get -d at the end of prepping new env

[mohammed90]

For some reason, downloading the dependencies resolves away the ambiguity. It is not clear why that is and is currently being researched.

Fixes caddyserver/caddy#4331

[francislavoie]

WAT.

Yeah, confirmed it works:

$ ./xcaddy build resolve-ambiguity --with github.com/mastercactapus/caddy2-proxyprotocol
2022/04/04 13:14:04 [INFO] Temporary folder: /tmp/buildenv_2022-04-04-1314.1987650476
2022/04/04 13:14:04 [INFO] Writing main module: /tmp/buildenv_2022-04-04-1314.1987650476/main.go
2022/04/04 13:14:04 [INFO] Initializing Go module
2022/04/04 13:14:04 [INFO] exec (timeout=10s): /usr/local/go/bin/go mod init caddy 
go: creating new go.mod: module caddy
go: to add module requirements and sums:
	go mod tidy

2022/04/04 13:14:04 [INFO] Pinning versions
2022/04/04 13:14:04 [INFO] exec (timeout=0s): /usr/local/go/bin/go get -d -v github.com/caddyserver/caddy/v2@resolve-ambiguity
...

2022/04/04 13:14:12 [INFO] exec (timeout=0s): /usr/local/go/bin/go get -d -v github.com/mastercactapus/caddy2-proxyprotocol 
go: added github.com/mastercactapus/caddy2-proxyprotocol v0.0.2
go: added github.com/mastercactapus/proxyprotocol v0.0.3
2022/04/04 13:14:13 [INFO] exec (timeout=0s): /usr/local/go/bin/go get -d -v  
go: downloading github.com/smallstep/cli v0.18.2
go: downloading github.com/google/cel-go v0.11.2
go: downloading go.step.sm/cli-utils v0.7.2
go: downloading github.com/antlr/antlr4 v0.0.0-20220314183648-97c793e446ba
2022/04/04 13:14:17 [INFO] Build environment ready
2022/04/04 13:14:17 [INFO] Building Caddy
2022/04/04 13:14:17 [INFO] exec (timeout=0s): /usr/local/go/bin/go mod tidy 
2022/04/04 13:14:18 [INFO] exec (timeout=0s): /usr/local/go/bin/go build -o caddy -ldflags -w -s -trimpath 
2022/04/04 13:14:52 [INFO] Build complete: ./caddy

[mholt]

Is the Go team aware of this? 🤔

[mohammed90]

Is the Go team aware of this? 🤔

Currently discussed in Slack: https://gophers.slack.com/archives/C9BMAAFFB/p1649082684242099

[bcmills]

FWIW, this turned out to be an interaction between go get and lazy module loading.

The final go get -d attempts to resolve the ambiguous package by adding or upgrading a dependency for it, and (somewhat surprisingly!) that succeeds. When go get arbitrarily adds one of the candidate modules as an explicit dependency, it causes that candidate to be preferred when loading packages (due to lazy module loading) and thus resolves the ambiguity.

go mod tidy, on the other hand, is not able to resolve the dependency because (unlike go get) it isn't in general allowed to fix problems by making arbitrarily choices. (That's somewhat related to golang/go#27899.)

In this case, it's a bit more confusing because the newly-added explicit dependency also happens to be one of the versions that was already present — but more distant — in the module graph. 😅

[mohammed90]

FWIW, this turned out to be an interaction between go get and lazy module loading.

The final go get -d attempts to resolve the ambiguous package by adding or upgrading a dependency for it, and (somewhat surprisingly!) that succeeds. When go get arbitrarily adds one of the candidate modules as an explicit dependency, it causes that candidate to be preferred when loading packages (due to lazy module loading) and thus resolves the ambiguity.

go mod tidy, on the other hand, is not able to resolve the dependency because (unlike go get) it isn't in general allowed to fix problems by making arbitrarily choices. (That's somewhat related to golang/go#27899.)

In this case, it's a bit more confusing because the newly-added explicit dependency also happens to be one of the versions that was already present — but more distant — in the module graph. 😅

Thank you, Bryan, for the explanation and the support through the prolonged conversation with us to understand this!