proposal: cmd/go: have `go get`... look in vendored caches for dependencies

[mcandre]

I already have gopkg.in/yaml.v2 in my vendor/ directory, managed with go mod vendor. However, when I run go get github.com/tsg/gotpl, this cache is ignored and the command fails due to how my particular network's proxies work.

Can we please have go get... check for dependencies in vendor/, for more reproducible development environments and less network strain?

[mvdan]

vendor/ contains packages, but go get in module mode downloads modules. Those are entirely different things. How exactly would this work?

/cc @bcmills

[bcmills]

Per https://golang.org/cmd/go/#hdr-Add_dependencies_to_current_module_and_install_them:

By default, get looks up the latest tagged release version, such as v0.4.5 or v1.2.3. If there are no tagged release versions, get looks up the latest tagged pre-release version, such as v0.0.1-pre1. If there are no tagged versions at all, get looks up the latest known commit.

The go command has know no way to know whether the contents in your vendor directory are the latest version.

[rsc]

As @mvdan and @bcmills pointed out, this is infeasible. The vendor directory by design does not contain full modules, only necessary packages for a build.

@mcandre, as of Go 1.14 the go command will load packages from vendor automatically when it exists, so that will help "more reproducible development environments and less network strain" during builds. But go get is an operation managing dependency versions. It necessarily has to talk to the network to find the latest version of the thing you asked to go get. (go get X with no version means go get X@latest.) If you are using go get in a CI environment as a synonym for go build or go install, use one of those instead.

[rsc]

Given that this is not possible - the vendor directory does not contain full modules, and people would object if it did - this seems like a likely decline.

Leaving open for a week for final comments.

[rsc]

No change in consensus so declining.