Lots of golang ports are downloading dependencies at build time

[amake (Aaron Madlon-Kay)]

With the introduction of the Go modules system, it's very easy to accidentally make a port that downloads dependencies at build time.

I want to add GOPROXY=off GO111MODULE=off to build.env to prevent this, but there are many ports that currently fail in my testing.

Discover ports using the golang-1.0 portgroup (currently 85):

find . -name Portfile | xargs grep -l -E 'PortGroup +golang' | xargs -n 1 dirname | xargs -n 1 basename

Of those, ports that failed to build with GOPROXY=off GO111MODULE=off appended to build.env:

port	maintainer	status
annie	@l2dy,openmaintainer
aws-vault	@herbygillot,openmaintainer
certigo	@herbygillot,openmaintainer
chezmoi	@herbygillot,openmaintainer
cloudmonkey	@herbygillot,openmaintainer
copilot	@herbygillot,openmaintainer
croc	@herbygillot,openmaintainer
elvish	@herbygillot,openmaintainer
evans	@herbygillot,openmaintainer
fzf	@cardi,openmaintainer
gitqlite	@herbygillot,openmaintainer
glow	@herbygillot,openmaintainer
go-migrate	@herbygillot,openmaintainer
golangci-lint	@herbygillot,openmaintainer
gore	@herbygillot,openmaintainer
gotop	@i0ntempest,openmaintainer
grpcurl	@herbygillot,openmaintainer
hugo	@cardi,openmaintainer
ipfs	@sirn,openmaintainer
istioctl	@nickolaev,openmaintainer	due to #61184
jenkins-cli	@harens,openmaintainer
k9s	@breun,openmaintainer
krew	@herbygillot,openmaintainer
kubergrunt	@herbygillot,openmaintainer	#61185
kustomize	@breun,openmaintainer
micro	@herbygillot,openmaintainer
mole	@herbygillot,openmaintainer
newreleases	@herbygillot,openmaintainer
pulumi	@herbygillot,openmaintainer
rclone	@eborisch,openmaintainer
scw	@dgsb,openmaintainer
staticcheck	@herbygillot,openmaintainer
syncthing	@lbschenkel,openmaintainer
tektoncd-cli	@herbygillot,openmaintainer
terragrunt	@mjrc,openmaintainer
trivy	@herbygillot,openmaintainer
uni	@herbygillot,openmaintainer
up	@herbygillot,openmaintainer
webify	@harens,openmaintainer
wtfutil	@herbygillot,openmaintainer
yq	@herbygillot,openmaintainer

I have not yet checked that each of these failures is from being unable to download dependencies, as opposed to e.g. something more esoteric about GO111MODULE.

[ryandesign (Ryan Carsten Schmidt)]

Herby, you may wish to know about this since you've been doing a lot of go-based ports.

[herbygillot (Herby Gillot)]

Thank you @ryandesign, @amake

I will look to transition more of the Go ports over time to using go.vendor. It will be cumbersome, but will give it a go.

[herbygillot (Herby Gillot)]

go2port goes not seem to work very well... the checksums that it generates for go.vendor don't always match what MacPorts sees.... so when attempting to build a Portfile derived from go2port, the build process immediately fails on checksum mismatches.

[amake (Aaron Madlon-Kay)]

go2port is very much a "best effort" tool :(

I just had a go at fixing the glow port ​here and noted the following tricky parts:

1. go2port 20200217 will duplicate some dependencies. I just fixed this and pushed an update to the port, so you should see it soon.
2. There were some checksum mismatches as you mentioned; surprisingly enough it seemed like GitHub sometimes served truncated tarballs, because deleting and re-downloading fixed it. This is quite troubling, but I'm not sure what I can do about it.
3. Simply pasting the generated go.vendors block is not enough; you also have to give the main distfile a filename. Until you do so, the checksum phase will fail in a way that makes it look like issue (2) above.

One issue you might run into is that custom domains are generally not supported by either go2port or the golang portgroup*. So far all the packages with custom domains I've seen have been mere redirects to a supported domain like github.com. If you encounter something else then it might be quite difficult to handle.

*Someone has ​offered a patch to support arbitrary domains in go2port but since the golang portgroup would also need a lot of work I haven't yet properly reviewed it.