x/vgo: vgo build and vgo mod -sync produce different list of dependencies

[dlsniper]

What version of Go are you using (go version)?

go version go1.10.3 linux/amd64
golang/vgo@f574d31

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

cross-platform issue

What did you do?

In the following case, having the files outside of GOPATH:

• main.go

package main

import "github.com/gorilla/mux"

func main() {
	m := mux.NewRouter()
	_ = m
}

• go.mod

module awesomevgoProject

Then run vgo build. Cleanup the go.mod file to the one in the issue and now run vgo mod -sync.

What did you expect to see?

• vgo build produces the following go.mod

module awesomevgoProject

require github.com/gorilla/mux v1.6.2

• vgo mod -sync produces the following go.mod

module awesomevgoProject

require (
	github.com/gorilla/context v1.1.1
	github.com/gorilla/mux v1.6.2
)

What did you see instead?

I expect the file to be similar in both cases.
And given that vgo build produces a working code, I expect that vgo build is the minimal source of truth in this case.

Maybe this works as expected but in this case, more documentation would be useful as vgo build will be significantly faster than vgo mod -sync in case of many dependencies that need to be downloaded if the pattern can replicate in larger projects.

[bcmills]

The difference here is in the build tags: mux/context_gorilla.go imports github.com/gorilla/context, but is guarded by a !go1.7 build tag. When you invoke vgo build, it is probably only updating the requirements that are affected by the current tags.

In contrast, vgo mod -sync intentionally ignores build tags: the go.mod file is also the input to vgo vendor, which is the support path for users on older versions of the go command.

[dlsniper]

Thank you for the update.

In this case, what is preferred to invoke? vgo build or vgo mod -sync?

Also, in the case of third-party tooling that wants to support users work on vgo enabled apps, what is preferred to run?

I understand the difference in these run modes but I think that in order to minimize the friction with developers, both commands should behave the same.
Imagine a case where a dependency will be present or not based on the user's operating system. In this case, it could potentially create unnecessary churn and additional confusion for reviewers as to why the go.mod file changes between users.

[bcmills]

To be clear: I'm not saying that vgo build and vgo mod -sync should produce different results. I'm just explaining the likely reason that they do today.

(I tend to agree with you that they should be equivalent, but that invariant has a non-trivial cost. I'm curious to find out @rsc's thoughts on the matter.)

[kardianos]

They should not be equivalent. go build should be lazy and do minimal work for that GOOS, GOARCH, and tag-set.

go mod x is for managing the mod requirements regardless of the current system setup. This is similar to how govendor works. This attribute is important.

One project I work on I develop on Linux and deploy to windows. I don't want my deploy step pulling down extra un-reviewed deps. So when I update dependencies they ignore current GOOS values. This is also why govendor had to reimplement package discovery.

Issue #25873 is about limiting the scope of the mod subcommand, but would not affect go build.

[bcmills]

I chatted a bit about this with Russ this morning, and his interpretation agrees with @kardianos' comment: vgo build does the minimal work needed to satisfy the imports of the requested packages for that particular build invocation. So I think this is working as intended.

Personally, I would recommend vgo build as the default during development, plus a vgo mod -sync in any commit to be tagged for release.