[MacPorts] #61192: Lots of golang ports are downloading dependencies at build time

[MacPorts]

#61192: Lots of golang ports are downloading dependencies at build time
-------------------------------------------------+-------------------------
  Reporter:  amake                               |      Owner:  (none)
      Type:  defect                              |     Status:  new
  Priority:  Normal                              |  Milestone:
 Component:  ports                               |    Version:
Resolution:                                      |   Keywords:
      Port:  annie aws-vault certigo chezmoi     |
  cloudmonkey copilot croc elvish evans fzf      |
  gitqlite glow go-migrate golangci-lint gore    |
  gotop grpcurl hugo ipfs istioctl jenkins-cli   |
  k9s krew kubergrunt kustomize micro mole       |
  newreleases pulumi rclone scw staticcheck      |
  syncthing tektoncd-cli terragrunt trivy uni    |
  up webify wtfutil yq nebula qri                |
-------------------------------------------------+-------------------------

Comment (by quentinmit):

 `GO111MODULES=off` is deprecated and scheduled to be removed soon:
 https://go.dev/blog/go116-module-changes

 Replying to [comment:55 amake]:
 > Replying to [comment:53 breun]:
 > > I must admit I do not completely understand what the problem exactly
 is.
 >
 > There are two problems:
 >
 > 1. Downloading dependencies outside of MacPorts' fetch mechanism
 prevents MacPorts from mirroring distfiles. That's bad for a number of
 reasons, such as: upstream could disappear, or we send a lot of traffic
 their way putting a strain on their infrastructure.
 > 2. Some build-time dependency fetching schemes lack a locking mechanism,
 so the exact version of the dependency used can differ depending on when
 exactly the build was performed. This is bad for reproducibility.

 (2) is a core feature of Go's module system; in fact *every* module
 dependency is pinned to a specific version by the `go.mod` and `go.sum`
 files in the repo. Turning off `GO111MODULE` actually causes the latest
 HEAD of each dependency to be used, so setting `GO111MODULE=off` does the
 opposite of what you are hoping for.

 I don't think there's an easy answer here; `go mod download` can be used
 as part of the `fetch` step to download all the dependencies, but that's
 still not going to use MacPorts's distfiles mechanism. Honestly I wouldn't
 worry about the load on the Go module proxies; they're provisioned at
 least as well as the distfiles network. But if you are worried, probably
 the best option would be to have the `fetch` step download module zip
 files from the module proxy, and prefill the local module cache in the
 `extract` step. Then `go build` will use the module zip files, and the
 module zip files can be downloaded as distfiles.

 You can also use `go mod vendor` to download all the dependencies as a
 source tree, but I don't know how to integrate that with distfiles. You
 would probably need extra magic to generate a tarball of the output of `go
 mod vendor` in the distfiles system.

-- 
Ticket URL: <https://trac.macports.org/ticket/61192#comment:100>
MacPorts <https://www.macports.org/>
Ports system for macOS