It's possible I'm just using this wrong and should be doing something else instead, so I'll describe the context: We use Go in BoringSSL for testing and various tools in our build. But we're a C/C++ library, so living in GOPATH doesn't make much sense. But living outside of GOPATH gets awkward when we want to use multiple packages.
Go modules seemed a good way to reuse Go code more idiomatically within our own tools and also reuse occasional external code. (We've currently vendored a bit of golang.org/x/crypto.)
I played with this a bit, and the former seems to work great. I then tried pulling in golang.org/x/crypto more normally. That too works great standalone, but our CI currently avoids depending on random external servers. (Though that particular module is hosted on googlesource.com too, so maybe that's actually fine?) Still, https://golang.org/cmd/go/#hdr-Modules_and_vendoring suggested go mod vendor plus passing -mod=vendor was the solution for this scenario, so I looked at that.
However, the go/build package (which I used to generate a depfile for integration into our buildsystem) shells out to go list but doesn't provide a way to pass -mod=vendor in, which means querying file lists internally fetches the module. https://golang.org/src/go/build/build.go#L1008
What did you expect to see?
Some ImportMode, Context setting, or environment variable corresponding to -mod=vendor.
What did you see instead?
Passing defaults in causes go list to hit the network if the dependency is uncached, with no way to change the setting.
The text was updated successfully, but these errors were encountered:
I suspect (given the brief details you provided) you'll want to switch to go/packages instead of go/build. go/build has very limited module support; go/packages has extensive module awareness and support go -mod=vendor as you describe.