Design: Why isn't gocomply looking in "$GOPATH/go/pkg/mod"?

[golightlyb]

The "$GOPATH/go/pkg/mod" directory already has license files for modules. If we could use that, gocomply becomes much, much simpler and faster.

gocomply is currently sidestepping the "$GOPATH/go/pkg/mod" directory because (emphasis mine):

The module download is split into two parts: downloading the go.mod and downloading the actual code. If you have dependencies only needed for tests, then they will show up in your go.mod, and go get will download their go.mods, but it will not download their code. The test-only dependencies get downloaded only when you need it, such as the first time you run go test.

This applies not just to test-only dependencies but also os-specific dependencies. For example if you use logrus but don't use Solaris, then the golang.org/x/sys go.mod needs to be downloaded, but not the code in that repo.

When you do split things out explicitly, then you'd have different version selection results for the different "scopes". You could potentially be using one version for a build and then get a different version for a test. That would be quite unfortunate. Having one unified go.mod avoids that potential problem.

So you're getting the fine-grained separation you want already, for free*, without having to maintain any explicit scopes, and without any possibility of inconsistency.

• The asterisk is that right now because we're still fetching git repos, even to get the go.mod, what I said isn't true. But once we have a better story for a proxy, it will become true, all with no effort. Because we do have a plan to get there, though, we're not planning to add any of these kinds of scopes as a temporary workaround. They'd just cause needless pain in the long run.

golang/go#26913 (comment) (10 Aug 2018)

• That proxy now exists
• However, it seems like go mod tidy is still fetching full git repos even for dependencies that aren't required
  • I don't think it is supposed to?
  • Can we rely on this?